CC BY
30МОДЕЛИРОВАНИЕ СЛОЖНЫХ ОРГАНИЗАЦИОННО-ТЕХНИЧЕСКИХ СИСТЕМ
УДК 004.75 DOI: 10.24412/2782-2141-2022-4-17-30
Моделирование передачи трафика IP по радиосети KB диапазона с помощью Network Simulator NS-2
Молокович И. А.
Аннотация. Постановка задачи: рассмотрены проблемы, связанные с передачей интернет пакетов по радиосетям коротковолнового диапазона и возможные пути их решения. Целью работы является реализация разработанной модели передачи пакетов Internet Protocol по радиосети коротковолнового диапазона в программном симуляторе network simulator ns-2 и проведение исследований пропускной способности радиосети. Используемые методы: имитационное моделирование с помощью программного симулятора телекоммуникационных сетей network simulator ns-2. Новизна состоит в том, что в реализации разработанной модели сети коротковолновой радиосвязи с помощью программного симулятора network simulator ns-2 используется прокси-сервер транспортного уровня. Результат заключается в том, что исследована пропускная способность коротковолновой радиосети при различных размерах сегмента сети, вероятности ошибки на бит и скорости передачи в радиоканале при использовании прокси-сервера и без него. Практическая значимость: полученные с помощью программного симулятора network simulator ns-2 результаты позволяют определить оптимальный с точки зрения пропускной способности размер сегмента сети для различной скорости передачи и вероятности ошибки на бит в радиоканале при использовании прокси-сервера и без него.
Ключевые слова: радиосеть, диапазон коротких волн, Internet Protocol, прокси-сервер, network simulator ns-2.
В настоящее время широкое применение средств радиосвязи в различных звеньях управления зависит от того, в какой мере они поддерживают доставку трафика IP {Internet Protocol) в рамках архитектуры сети связи. При использовании средств радиосвязи коротковолнового (KB) диапазона необходимо решать такие проблемы, как задержка и качество обслуживания. В статье сначала рассмотрены характерные проблемы сетевых коммуникаций по беспроводным каналам на основе протокола IP. Далее рассмотрены известные методы эффективной связи на основе протокола IP в таких условиях и показано, как новые технологии могут повысить эффективность радиоканалов KB диапазона для передачи сетевого трафика IP.
Существуют различные подходы к обеспечению передачи в радиоканалах KB диапазона сообщений различных приложений, таких как мультимедиа (в первую очередь файлов изображений), электронная почта (потенциально с большими вложениями файлов и возможностями сохранения и пересылки), а также управляющей информации [1]. Приложения управления являются важными элементами растущего ассортимента приложений, которые должны поддерживать сети связи различных звеньев управления, использующие стандартные протоколы TCP/IP для обмена данными по разнородным средам передачи, включая как проводные, так и беспроводные подсети. Протоколы TCP/IP налагают особые требования и ограничения на механизмы физического и канального уровней, используемые для доставки сетевого трафика. Необходимые решения этих проблем для радиосвязи KB диапазона еще только разрабатываются.
Связь в тактическом звене управления - это область, в которой технология KB радиосвязи может быть особенно полезна; однако растущее внедрение доктрин сетецентрической войны [2] влечет за собой то, что успешное применение технологии KB
радиосвязи в этой области потребует разумных подходов к предоставлению трафика TCP/IP через радиоканалы KB диапазона.
Для доставки трафика IP преимущественно используется один из двух протоколов транспортного уровня: TCP, который обеспечивает надежную службу доставки, ориентированную на подключение, или UDP, предоставляющий службу дейтаграмм без подключения. Недавние исследования этих двух протоколов показывают, что на TCP по-прежнему приходится значительная часть объема трафика, в диапазоне от 70 до 90 %, а остальная часть почти полностью приходится на UDP [3]. Трафик TCP состоит в основном из трафика HTTP/S, в то время как трафик UDP включает трафик DNS и, все чаще, потоковые медиа, хотя значительная часть потокового медиаконтента также доставляется по протоколу TCP [4]. Преобладание TCP можно объяснить тем, что он обеспечивает функциональность - надежную доставку по заказу - удовлетворяющую требованиям значительного большинства трафика приложений. Если разработчики приложений по какой-либо причине отказываются от использования TCP, им обычно требуется разработать протокол прикладного уровня, обеспечивающий эту функциональность. Механизмы контроля перегрузки, встроенные в TCP, также играют важную роль в стабилизации сетей TCP/IP; по существу, обходя эти механизмы и используя UDP вместо TCP, потенциально можно усложнить управление сетью [5].
Было замечено, что беспроводные линии связи создают особые проблемы для доставки ГСР-трафика из-за их относительно ограниченных скоростей передачи данных, высоких задержек доставки и значительных частот ошибок в канале [6, 8]. Поскольку высокочастотные линии связи проявляют эти характеристики во многих случаях в еще большей степени, чем другие беспроводные носители, доставка ГСР-трафика по KB радиоканалам, как было замечено, является особенно сложной задачей [7]. По этим причинам наметилась тенденция избегать использования TCP поверх беспроводных носителей, предпочитая вместо этого использовать UDP для приложений, разработанных специально для использования в беспроводных сценариях. Это может быть эффективным подходом при условии, что специально разработанные протоколы прикладного уровня, используемые этими приложениями, эффективно работают через беспроводные каналы. Однако эта стратегия имеет потенциально серьезные недостатки:
— это ограничивает сети поддержкой только специально разработанных приложений, не позволяя предоставить возможности доставки, характерные для всех приложений;
— разработчики приложений должны попытаться предусмотреть все разнообразие беспроводных сред, через которые может использоваться приложение, и оптимизировать свои протоколы с учетом характеристик этих сред, что является задачей, выходящей за рамки набора навыков и проблем типичных разработчиков приложений;
— если разработчики систем беспроводной связи пытаются предоставить возможности передачи данных, оптимизированные для доставки трафика приложений TCP/IP, их задача значительно усложняется требованием настройки и оптимизации их средств передачи данных для протоколов, используемых новыми приложениями.
По этим причинам было бы весьма полезно, если бы можно было разработать и внедрить в радиосистемы достаточно эффективные механизмы беспроводной доставки ГСР-трафика. Если бы это было успешным, будущие разработчики приложений были бы освобождены от необходимости разрабатывать специализированные протоколы прикладного уровня. Кроме того, применимого подмножества этих методов может быть достаточно и для эффективной доставки беспроводного t/DP-трафика, где это необходимо.
RFC 3135 [9] описывает различные методы прокси-сервера, повышающие производительность — Performance Enhancing Proxy (PEP), предназначенные для устранения некоторых недостатков в производительности TCP, возникающих на каналах с высокой задержкой, в частности на спутниковых каналах. Широко используемые компоненты PEP
используют такие методы, как разделение соединений и подмена TCP, для смягчения сквозных ухудшений производительности из-за увеличения задержки и потери пакетов [10]. Эти методы были достаточно хорошо проверены для спутниковых линий связи, однако количество сообщений об опыте использования таких методов по радиоканалам KB диапазона довольно ограничено.
Рассмотрим более подробно применение прокси-серверов для повышения производительности. Прокси-серверы для повышения производительности (PEP) — это сетевые агенты, предназначенные для улучшения сквозной производительности некоторых протоколов связи. Стандарты PEP определены в RFC 3135 (PEP, предназначенные для смягчения связанных с каналом деградаций) и RFC 3449 (влияние асимметрии сетевого пути на производительность протокола TCP).
PEP может функционировать на любом уровне стека протоколов, но обычно используются реализации PEP, функционирующие на транспортном или прикладном уровнях. Кроме того, PEP может работать на канальном уровне или на нескольких уровнях стека протоколов. Большинство реализаций PEP транспортного уровня взаимодействуют с протоколом TCP (TCP PEP). TCP PEP может использоваться для изменения интервала подтверждений с целью повышения производительности, а также для изменения поведения ГСР-соединения путем генерации локальных подтверждений сегментам данных TCP с целью повышения пропускной способности соединения. PEP прикладного уровня может иметь такую же функциональность, как и прокси-сервер прикладного уровня, но расширенную для оптимизации работы прикладного протокола.
Доступные реализации PEP используют разные методы для повышения производительности. PEP может либо «разбивать» соединение, либо «отслеживать» его. В первом случае прокси-сервер притворяется противоположной конечной точкой соединения в каждом направлении, буквально разделяя соединение на два. В последнем случае прокси-сервер управляет передачей сегментов TCP в обоих направлениях путем фильтрации и восстановления подтверждений в существующем соединении.
Реализация TCP с разделенным соединением завершает ГСР-соединение, полученное от конечной системы, и устанавливает соответствующее ГСР-соединение с другой конечной системой. В распределенной реализации PEP это обычно делается для того, чтобы использовать третье соединение между двумя PEP, оптимизированными для связи этих конечных систем. Это может быть ГСР-соединение, оптимизированное для данного канала связи, или это может быть другой протокол, например, проприетарный, работающий поверх протокола UDP. Кроме того, распределенная реализация может использовать отдельное соединение между прокси-серверами для каждого ГСР-соединения или данные из нескольких ГСР-соединений могут мультиплексироваться через одно соединение между PEP.
PEP могут быть интегрированными или распределенными. Интегрированный PEP будет работать на одном устройстве, в то время как распределенный PEP должен быть установлен на обеих сторонах канала, что приведет к снижению производительности.
Реализация PEP может быть симметричной или асимметричной. Симметричные PEP используют идентичное поведение в обоих направлениях. Действия, предпринимаемые PEP, происходят независимо от того, от какого интерфейса получен пакет. Асимметричные PEP работают по-разному в каждом направлении, что может привести, например, к повышению производительности только в одном направлении линии связи.
Прокси-сервер Snoop [9] является примером интегрированного прокси-сервера. Представляет собой протокол канального уровня с поддержкой протокола TCP. Он разработан, чтобы скрыть помехи или потерю пакетов по причине коллизий в беспроводном канале. Прокси-серверы Snoop обнаруживают потери, отслеживая передачи протокола TCP на предмет дублирования подтверждений. Когда прокси-сервер Snoop получает
дублирующие подтверждения протокола TCP, указывающие на потерю пакета, они будут отброшены без уведомления, а потерянный пакет данных будет повторно передан. ТСР-отправитель не должен знать о потере, это должно предотвратить ненужное уменьшение ГСР-отправителями окна TCP.
Для имитации передачи данных протоколом транспортного уровня TCP с использованием network simulator ns-2 необходимо написать сценарий Tel ns-2. В [11] с использованием ns-2 проведено моделирование пакетной радиосети со скоростью передачи 1200 бит/с и задержкой передачи 2 мс. Представлена структура сценария Tel ns-2, который имитирует передачу файлов с использованием протоколов FTP и TCP Reno по пакетной радиосети. Ниже обсуждаются основные инструкции сценария Tel ns-2, необходимые для имитации передачи данных по протоколам FTP и TCP с использованием прокси-сервера Snoop через радиосеть KB диапазона.
KB радиосеть, которая моделируется с использованием ns-2, характеризуется скоростью передачи 1200 9600 бит/с [7], задержкой передачи 8 -г- 12 мс и вероятностью ошибки на бит 10"3 -=- 10"4. На рис. 1 показана физическая топология этой сети, в то время как на рис. 2 показана логическая топология этой сети. Логическая топология, показанная на рис. 2, будет моделироваться с помощью ns-2.
Физическая топология, показанная на рис. 1, включает четыре узла. Логическая топология, показанная на рис. 2, включает узлы отправителя и получателя, два транзитных узла, прокси-сервер Snoop, а также модуль битовой ошибки, который подключен к соединению между отправителем и получателем и имитирует ошибки в радиоканале.
Рис. 2. Логическая топология радиосети
На рис. 3 показан сценарий Tel ns-2, который имитирует передачу файла с использованием топологии, показанной на рис. 2. Скорость передачи и задержка передачи составляют 1200 бит/с и 10 мс соответственно. Цифры в начале каждой строки на рис. 3
являются номерами строк. Они включены здесь в целях иллюстрации и не являются фактическими инструкциями Tel.
1 ргос finish {} {
2 global ns
3 global filed
4 $ns flush-trace
5 close $filed(tr)
6 close $filed(namtr)
7 exec awk -f pdr_tcp.awk prn_snoop.tr &
8 exec awk -f overhead_dv.awk prn_snoop.tr &
9 exec nam prn.nam &
10 exit 0 11}
12 puts "sourcing ../../lan/vlan.tcl..."
13 source /~/ns-allinone-2.34/ns-2.34/tcl/lan/vlan.tcl
14 source /~ /ns-allinone-2.34/ns-2.34/tcl/lan/ns-mac.tcl
15 set opt(start_time) 0.0
16 set opt(stop_time) 50.0
17 set opt(bw) 1200; # transmission rate
18 set opt(del) 0.01; # transmission delay
19 set opt(ifq) Queue/DropTail
20 set opt(error_unit) bit
21 set opt(error_rate) 0.0001; # The bit error rate
22 set opt(file_size) 65536
23 set opt(sgmt_size) 1024; # the TCP agent's packetSize
24 set opt(ack_size) 40
25 set opt(max win size) 65536;
26 set opt(src) TCP/Reno
27 set opt(sink) TCPSink
28 set opt(app) FTP
29 set opt(node) 2
30 set opt(mac) Mac/802 3
31 set opt(chan) Channel
32 set opt(ll) LL/LLSnoop
33 set ns [new Simulator]
34 set filed(tr) [open "prn_snoop.tr" w]
35 $ns trace-all $filed(tr)
36 set filed(namtr) [open "prn-snoop.nam" w]
37 $ns namtrace-all $filed(namtr)
38 proc create-topology {} {
39 global ns opt
40 global lan node s d
41 set num $opt(node)
42 for {set i 1} {$i < $num} {incr i} {
43 set node($i) [$ns node]
44 lappend nodelist $node($i)
45 }
46 set lan [$ns make-Ian $nodelist $opt(bw) \
47 $opt(delay) $opt(ll) $opt(ifq) $opt(mac) $opt(chan)]
48 set opt(ll) LL/LLSnoop
49 set opt(ifq) Queue/DropTail
50 $opt(ifq) set limit_ 100
51 # set up snoop agent
52 set node(O) [$ns node]
53 $lan addNode [list $node(0)] $opt(bw) $opt(delay) $opt(ll) $opt(ifq) $opt(mac)
54 # set source and connect to node(O)
55 set s [$ns node]
56 $ns duplex-link $s $node(0) 1200 0.002 DropTail
57 $ns queue-limit $s $node(0) 65536
58 $ns duplex-link-op $s $node(0) orient right
59 # set dest and connect to node(l)
60 set d [$ns node]
61 $ns duplex-link $node(l) $d 1200 0.002 DropTail
62 $ns queue-limit $node(l)$d 65536
63 $ns duplex-link-op $d $node(l) orient left
64 }
65 create-topology
66 set error model [new ErrorModel]
67 $error_model unit $opt(error_unit)
68 $error_model set rate_ $opt(error_rate)
69 $error_model ranvar [new RandomVariable/Uniform]
70 $error_model drop-target [new Agent/Null]
71 $error_model datapktsize $opt(sgmt_size)]
72 $error_model cntrlpktsize opt(ack_size)]
73 $ns lossmodel $error_model $s $node(0)
74 set error_model [new ErrorModel]
75 $error_model unit $opt(error_unit)
76 $error_model set rate_ $opt(error_rate)
77 $error_model ranvar [new RandomVariable/Uniform]
78 $error_model drop-target [new Agent/Null]
79 $error_model datapktsize $opt(sgmt_size)]
80 $error_model cntrlpktsize opt(ack_size)]
81 $ns lossmodel $error_model $d $node(l)
82 Agent/TCP set packetSize_ $opt(sgmt_size)
83 Agent/TCPSink set packetSize_ $opt(ack_size)
84 Agent/TCP set window_ [expr $opt(max_win_size) / $opt(sgmt_size)];# window size
85 Agent/TCP set windowInit_ 1; # initial window size
86 set color(0) red
87 $ns color 0 $color(0)
88 # Set a TCP connection
89 set tcpO [new Agent/TCP/Reno]
90 $tcp0 set backoff_ 2
91 $ns attach-agent $s $tcp0
92 set tcp snkO [new Agent/TCPSink]
93 $ns attach-agent $d $tcp_snk0
94 $ns connect $tcp0 $tcp_snk0
95 set ftpO [$tcp0 attach-app $opt(app)]
96 set numsegs [expr $opt(file_size) / $opt(sgmt_size)]
97 set rem [expr $opt(file_size) % $opt(sgmt_size)]
98 if {$rem != 0} {set num_segs [expr $num_segs + 1]}
99 if {$num_segs == 0} { set num segs 1 }
100 $ns at $opt(start_time) "$ftp0 produce $num_segs"
101 $ns at $opt(stop_time) "finish"
102 $ns run
103 exit 0
Рис. 3. Пример сценария ns-2 Tel для передачи файлов с использованием протоколов FTP и TCP Reno с PEP
Процедура завершения, указанная в строках 1-11 рис. 3, вызывается ns-2 по окончании моделирования. Симулятор ns-2 заканчивает работу на строке 103 рис. 3. Процедура завершения удаляет данные, еще не записанные в файлы трассировки, как указано в filed(tr) и filed(namtr), закрывает оба файла трассировки, а затем завершает работу. В строках 15-32 рис. 3 определен ассоциативный массив с именем optQ. Значения, помещенные в optQ, будут использоваться позже в сценарии Tel. Значения для opt(file_size), opt(sgmt_size), opt(ack_size) и opt(max_win_size) указаны в байтах (строки 22-25 рис. 3).
Строка 26 рис. 3 определяет opt(src) как агент TCP, используемый во время моделирования. Значение, которое используется для целей моделирования, - это TCP/Reno. Симулятор ns-2 позволяет моделировать несколько других агентов TCP, включая TCP (т. е. обычный TCP), TCP/NewReno, TCP/Vegas, TCP/Sackl и TCP/Fack. В строке 33 рис.3 определен экземпляр имитатора ns-2. Поскольку С++ и ОТс\ являются объектно-ориентированными языками, это означает, что был создан объект класса симулятора ns-2.
В строках 34-37 рис. 3 открывается файл трассировки и файл трассировки nam, чтобы принять данные трассировки, сгенерированные симулятором ns-2, а также инициализируется средство трассировки ns-2.
В строках 38-64 рис. 3 определена процедура создания топологии сети. Строки 39-45 определяют создание узлов отправителя s, получателя d и двух промежуточных узлов, заданных параметром opt(node). Строки 46-47 задают характеристики виртуального канала, образованного прокси-сервером Snoop. Строка 48 задает использование на канальном уровне протокола Snoop с поддержкой протокола TCP. Строки 52-53 определяют создание узла (0) с агентом Snoop и виртуального канала между узлами (0) и (1). Строки 55-58 рис. 3 определяют создание узла-отправителя и характеристики подключения к узлу (0). Аналогично строки 60-63 рис. 3 определяют создание узла-получателя и характеристики подключения к узлу (1). Определена пропускная способность, optQrw), задержка передачи, opt(del) и тип очереди интерфейса, opt(ifq), а длина очереди установлена в 64 Кбайта.
В строке 65 рис. 3 запускается процедура создания топологии сети.
В строках 66-73 рис. 3 описано создание модели ошибок для данных, которые передаются между отправителем и узлом (0), в строках 74-81 рис. 3 описано создание модели ошибок для данных, которые передаются между узлом (1) и получателем. Модель ошибки будет действовать как устройство помех, показанное на рис. 1. Частота битовых ошибок определяется переменной opt(error_rate) в строке 21. Частота ошибок 0,0 означает, что данные не повреждены во время передачи. Частота ошибок 0,0001 (т. е. 1,0е-04) указывает, что 1 бит из 10 000 будет поврежден при равномерном распределении.
Строки 82-85 рис. 3 определяют переменные размера пакетов агента TCP, window_ (т. е. размер окна) и windowInit_ (т. е. начальный размер окна). Переменные opt(sgmt_size), opt(ack_size) и opt(max_win_size) необходимы для определения этих значений. Значения по умолчанию для packetSizewindow_ и windowInit_ равны 1000, 20 и 1 соответственно [12]. Эти значения также определены в файле ns-2/tcMib/ns-default.tcl из дистрибутива UNIX/Linux ns-2.
Определение цвета передачи данных, как показано программой визуализации nam, выполняется в строках 86-87 рис. 3. Можно определить множество цветов, включая красный (как показано), синий, фиолетовый, оранжевый или черный. В общем случае «имя цвета должно быть одним из имен, перечисленных в базе данных цветов в XI1 (/usr/X11 äib/rgb.txt)» [12].
Агент TCP определен в строке 89 рис. 3. В частности, агент TCP/Reno подключается к узлу (0), отправителю, a TCPSink подключается к узлу (1), получателю. В строке 95 рис. 3 определено приложение FTP, которое подключается к агенту TCP, определенному в строке 89.
По умолчанию .FTP-приложение ns-2 непрерывно генерирует и передает новый пакет каждый раз, когда получает подтверждение для любого пакета в окне перегрузки. Передача пакетов продолжается до тех пор, пока не наступит время остановки, как определено параметром opt(stop_time) в строке 101 рис. 3. В строках 96-99 рис. 3 определено максимальное
количество пакетов, которые должно передавать приложение FTP, и оно основано на размере файла и размере сегмента. Здесь размер сегмента и размер пакета являются синонимами. Как минимум, один сегмент будет передан приложением FTP (строка 99).
Строка 100 рис. 3 определяет время, в которое приложение FTP начнет передавать сегменты. Как указывалось ранее, время, в которое закончится моделирование ns-2, указано в строке 101 рис. 3. Это значение хранится в переменной opt(stop_time). Математически уравнение для времени передачи может быть использовано для определения значения opt(stopJime). Строка 102 рис. 3 запускает моделирование ns-2, а строка 103 рис. 3 завершает сценарий Tel.
Сценарий Tel, показанный на рис. 3, имеет множество переменных; каждой из них может быть присвоено несколько значений. Выполнение симулятора ns-2 по сценарию Tel, показанному на рис. 3, представляет собой «запуск» с использованием этих переменных. Чтобы изменить значение переменной, необходимо открыть файл сценария Tel, внести конкретное изменение, сохранить и закрыть файл, а симулятор ns-2 повторно запустить в файле сценария Tel. В оболочке UNIX командой для выполнения сценария Tel ns-2 является $nsprnsnoop.tcl, где $ — приглашение оболочки UNIX, ns - двоичный файл, aprnsnoop.tcl — имя файла, содержащего сценарий Tel ns-2.
Файл трассировки ns-2, показанный на рис. 4 и 5, был сгенерирован сценарием Tel, показанным на рис. 3 (протоколы FTP и TCP Reno). Файл трассировки ns-2 получает данные, сгенерированные симулятором ns-2 во время выполнения. В строках 25 и 26 рис. 3 открыт файл трассировки ns-2 с именем "out.tr". Средство трассировки ns-2 инициализируется для записи выходных данных в этот файл. В строках 27 и 28 открывается файл трассировки ns-2 пат, и средство трассировки ns-2 инициализируется для генерации выходных данных трассировки ns-2 пат.
Как упоминалось ранее в этой статье, предлагается дополнительный пакет программного обеспечения ns-2, который позволяет исследователям визуально просматривать результаты моделирования ns-2. То есть пат интерпретирует данные в файле трассировки пат (т. е. out. пат) и отображает выходные данные графически. Выходные данные, содержащиеся в файлах трассировки пат, могут помочь отлаживать сценарии Tel ns-2.
Как и на рис. 3, на рис. 4 показан ориентированный слева номер, помогающий идентифицировать конкретные строки файла трассировки. Все записи (т. е. строки) в файле трассировки ns-2 состоят из 12 полей. Первое поле (т. е. начало строки) - это либо символ «+», «-», либо «г». Символ «+» указывает операцию постановки сегмента в очередь, а символ «-» определяет операцию удаления сегмента из очереди. Операции постановки в очередь и удаления из очереди выполняются в источнике. Символ «г» указывает операцию приема сегмента, которая выполняется в пункте назначения.
Во втором поле указывается время, в которое произошла операция в симуляторе ns-2. Третье и четвертое поля численно определяют, какой узел является передатчиком (т. е. первым из двух чисел), а какой — получателем (т. е. вторым из двух чисел). Пятое поле показывает описательное имя, которое представляет тип передаваемого пакета (т. е. tep или аск). Шестое поле показывает размер сегмента в байтах, как закодировано в заголовке протокола IP.
Седьмое поле представляет собой список из семи флагов (не более), который описывает конкретную строку. Четыре следующих флага используются для определения ECN (явное уведомление о перегрузке) в TCP/IP. Флаг "Е' используется для указания «Возникшей перегрузки», флаг "7V" указывает «Индикации транспорта с поддержкой ENC в заголовке IP», флаг "С" указывают "ECN-эхо", а флаг "А" используется для указания «Окно перегрузки уменьшено в заголовке TCP». Можно определить два дополнительных флага: "Р" для «Приоритета» и "F" для «Быстрого запуска TCP».
1 + 032 top 40-------03.0 4.000
2 - 0 3 2 top 40-------0 3.0 4.0 0 0
3 r 0.043333 3 2 top 40 — — 0 3.0 4.0 0 0
4 h 0.043333 2 1 top 40 — — 0 3.0 4.0 0 0
5 + 0.053333 2 1 top 40 — — 0 3.0 4.0 0 0
6 - 0.053333 2 1 top 40 — — 0 3.0 4.0 0 0
7 r 0.116671 1 0 top 40 — — 0 3.0 4.0 0 0
8 + 0.116671 0 4 top 40 — — 0 3.0 4.0 0 0
9 -0.116671 0 4 top 40 — — 0 3.0 4.0 0 0
10 r 0.160004 0 4 top 40 — — 0 3.0 4.0 0 0
11 + 0.160004 4 Oack 40 — — 0 4.0 3.0 0 1
12 -0.160004 4 Oack 40 -— — 0 4.0 3.0 0 1
13 r 0.203337 4 Oack 40 -— — 0 4.0 3.0 0 1
14 h 0.203337 0 1 ack 40 — — 0 4.0 3.0 0 1
15 + 0.213337 0 1 ack 40 — — 0 4.0 3.0 0 1
16 -0.213337 0 1 ack 40 -— — 0 4.0 3.0 0 1
17 r 0.276675 1 2 ack 40 — — 0 4.0 3.0 0 1
18 + 0.276675 2 3 ack 40 — — 0 4.0 3.0 0 1
19 -0.276675 2 3 ack 40 — — 0 4.0 3.0 0 1
20 r 0.320008 2 3 ack 40 — — 0 4.0 3.0 0 1
Рис. 4. Пример файла трассировки ns-2
Восьмое поле определяет идентификатор потока протокола IP как указано в протоколе IP версии 6. В девятом и десятом полях указываются числовые адреса узла источника и узла назначения, в то время как в одиннадцатом поле указывается порядковый номер. Начиная с ns-2, версия 2, это делают только агенты, желающие генерировать порядковые номера. Двенадцатое и последнее поле представляет уникальный идентификационный номер пакета.
Строки 1-20 рис. 4 показывают передачу первых двух сегментов, связанных с 3-сторонним рукопожатием протокола TCP. Завершение «рукопожатия» происходит, когда первый сегмент в 1500 байт передается от узла 3 (узел s в сценарии Tel на рис. 3) к узлу 4 (узел d в сценарии Tel на рис. 3) через узлы 2, 1 и 0 (узлы 0, прокси-сервер Snoop на узле 0 и узел 1 соответственно в сценарии Tel на рис. 3) в строках 21-68 (рис. 5). Сегмент размером 1500 байта состоит из 1460 байт данных и 40-байтового заголовка. Строки 41, 42, 47, 48-50, 65-68 показывают подтверждения, отправленные узлами получателями узлам отправителям в ответ на получение сегмента.
В [7] приведены результаты измерений, выполненных для различных приложений стека протоколов TCP/IP, работающих по KB радиоканалу с использованием протокола IP и STANAG 5066. На основании выполненных измерений делается вывод о том, что использование протокола IP значительно снижает производительность. Альтернативный поход заключается в использовании прокси-сервера и специализированных протоколов.
С помощью представленного выше сценария Tel были произведены измерения производительности фрагмента радиосети при передаче файла размером 65536 байт по протоколу FTP, скорости в радиоканале 1200, 9600 бит/с, размере ГСР-сегмента 500, 1500 байт, задержке в радиоканале 10 мс, вероятности ошибки на бит 10"3, 10"4 без использования прокси-сервера Snoop (табл. 1) и с использованием прокси-сервера Snoop (табл. 2). Размер сегмента TCP выбран исходя из типичных значений размера MTU (Maximum Transmission Unit), которые составляют 500 байт для широкополосного трафика и 1500 байт для трафика локальной сети [7].
21 + 0.320008 3 2 й;р 1500 -------0 3.0 4.0 1 2
22 - 0.320008 3 21ср 1500- ------0 3.0 4.0 1 2
23 + 1.280008 3 21ср 1500 —А— 0 3.0 4.0 1 3
24 - 1.570008 3 21ср 1500- -А— 0 3.0 4.0 1 3
25 г 1.580008 3 2 Кр 1500 - ------0 3.0 4.0 1 2
26 Ь 1.580008 2 Нср 1500 - -------0 3.0 4.0 1 2
27 + 1.590008 2 Пер 1500 -------0 3.0 4.0 1 2
28 - 1.590008 2 11ср 1500- ------0 3.0 4.0 1 2
29 + 2.680641 2 11ср 1500 -------0 3.0 4.0 1 2
30 г 2.830008 3 2 й;р 1500- -А—0 3.0 4.0 1 3
31 112.830008 2 11ср 1500- -А— 0 3.0 4.0 1 3
32 + 2.840008 2 1 й;р 1500 —А— 0 3.0 4.0 1 3
33 - 2.861675 2 Пер 1500- ------0 3.0 4.0 1 2
34 г 2.861679 1 01ср 1500- ------0 3.0 4.0 1 2
35 + 2.861679 0 41:ср 1500 -------0 3.0 4.0 1 2
36 - 2.861679 0 4 йф 1500- ------0 3.0 4.0 1 2
37 + 3.200008 3 21ср 1500 —А— 0 3.0 4.0 1 4
38 -3.200008 3 2 й;р 1500- -А— 0 3.0 4.0 1 4
39 + 3.930641 2 1 Щ 1500 -------0 3.0 4.0 1 2
40 г 4.121679 0 41:ср 1500- -------0 3.0 4.0 1 2
41 + 4.121679 4 Оаск 40 — — 0 4.0 3.0 1 5
42 -4.121679 4 Оаск 40 — ■—0 4.0 3.0 1 5
43 - 4.133341 2 11вр 1500 - -А— 0 3.0 4.0 1 3
44 г 4.133345 1 0й;р 1500- -------0 3.0 4.0 1 2
45 + 4.133345 0 41:ср 1500 -------0 3.0 4.0 1 2
46 - 4.133345 0 41ср 1500 - -------0 3.0 4.0 1 2
47 г 4.165012 4 0 аск 40 — -—0 4.0 3.0 1 5
48 Ь 4.165012 0 1 аск 40 — — 0 4.0 3.0 1 5
49 + 4.175012 0 1 аск 40 — -----0 4.0 3.0 1 5
50 -4.175012 0 1 аск 40 — —- 0 4.0 3.0 1 5
51 г 4.460008 3 2 Кр 1500 - -А— 0 3.0 4.0 1 4
52 Ь 4.460008 2 1 Юр 1500 —А—0 3.0 4.0 1 4
53 + 4.470008 2 1 й;р 1500 —А— 0 3.0 4.0 1 4
54 г 5.393345 0 4 Ьр 1500 - -------0 3.0 4.0 1 2
55 + 5.393345 4 0 аск 40 — -----0 4.0 3.0 1 6
56 - 5.393345 4 0 аск 40 — — 0 4.0 3.0 1 6
57 - 5.405008 2 1 1ср 1500 - -------0 3.0 4.0 1 2
58 г 5.405012 1 01ср 1500- -А— 0 3.0 4.0 1 3
59 + 5.405012 0 41:ср 1500 __А—0 3.0 4.0 1 3
60 -5.405012 0 41ср 1500 - -А— 0 3.0 4.0 1 3
61 г 5.436679 4 0 аск 40 — — 0 4.0 3.0 1 6
62 И 5.436679 0 1 аск 40 — — 0 4.0 3.0 1 6
63 + 5.446679 0 1 аск 40 - -----0 4.0 3.0 1 6
64 -5.49502 0 1 аск 40----- -0 4.0 3.0 1 6
65 г 5.495024 1 2 аск 40 — — 0 4.0 3.0 1 5
66 + 5.495024 2 3 аск 40 - -----0 4.0 3.0 1 5
67 - 5.495024 2 3 аск 40 — — 0 4.0 3.0 1 5
68 г 5.538357 2 3 аск 40 — — 0 4.0 3.0 1 5
Рис. 5. Продолжение файла трассировки ия-2
Таблица 1
№ n/n Скорость, бит/с Размер ГСР-сегмента, байт Вероятность ошибки на бит Пропускная способность, бит/с
1 1200 500 10"4 1160
2 9600 500 10"4 9200
3 1200 500 ю-3 200
4 9600 500 10"3 1000
5 1200 1500 10"4 870
6 9600 1500 10"4 5500
7 1200 1500 ю-3 -
8 9600 1500 10"3 -
Таблица 2
№ п/п Скорость, бит/с Размер ГСР-сегмента, байт Вероятность ошибки на бит Пропускная способность, бит/с
1 1200 500 10"4 1000
2 9600 500 10"4 6800
3 1200 500 ю-3 470
4 9600 500 ю-3 600
5 1200 1500 10"4 1100
6 9600 1500 10"4 5200
7 1200 1500 10"3 600
8 9600 1500 ю-3 500
Анализ полученных результатов показывает, что использование прокси-сервера Snoop позволяет повысить пропускную способность на скорости 1200 бит/с для размера ГСР-сегмента 500 байт при вероятности ошибки на бит 10"3 и для размера сегмента 1500 байт при вероятности ошибки на бит 10"3 и 10^, на скорости 9600 бит/с повышение пропускной способности происходит при размере ГСР-сегмента 1500 байт и вероятности ошибки на бит 10"3.
Без использования прокси-сервера практически нет обмена при размере сегмента 1500 байт, вероятности ошибки на бит 10"3 на скоростях 1200 и 9600 бит/с.
При использовании прокси-сервера и вероятности ошибки на бит 10"3 для скорости 1200 бит/с максимальная пропускная способность достигается при размере ГСР-сегмента 1500 байт, на скорости 9600 бит/с максимальная пропускная способность достигается при размере ГСР-сегмента 500 байт. Причем значения пропускной способности на скоростях 1200 и 9600 бит/с при размере ГСР-сегмента 500 и 1500 байт отличаются незначительно.
В начале моделирования значение пропускной способности колеблется скачкообразно, с увеличением времени моделирования пропускная способность сходится к максимальным значениям и далее остается практически неизменной (рис. 6).
Полученные значения пропускной способности при вероятности ошибки на бит 10"3 значительно ниже, чем приведенные в [7] при таких же значениях MTU. В [7] максимальная пропускная способность 5104 бит/с достигается при размере MTU 1500 байт на скорости 9600 бит/с, на скорости 1200 бит/с максимальная пропускная способность 798 бит/с достигается при размере MTU1500 байт.
При использовании прокси-сервера и вероятности ошибки на бит 10"4 для скорости 1200 бит/с максимальная пропускная способность достигается при размере ГСР-сегмента 1500 байт, а на скорости 9600 бит/с максимальная пропускная способность достигается при размере TCP-сегмента 500 байт. Полученные значения пропускной способности при вероятности ошибки на бит 10"4 сопоставимы с значениями, приведенными в [7] при таких же значениях MTU. Без прокси-сервера при увеличении вероятности ошибки на бит до 10"3 обмен данными есть только при размере сегмента 500 байт.
Рис. 6. Зависимость пропускной способности радиоканала со скоростью 9600 бит/с, размере ГСР-сегмента 500 байт, вероятности ошибки на бит 10"4 с использованием прокси-сервера Snoop от времени передачи
Литература
1. Кирносов А. А., Коржаков Д. А., Потапов И. В., Хайрулин Т. Р. Автоматизация обмена электронной почтой в коротковолновом радиоканале // Техника радиосвязи. 2019. Вып. 4 (43). С. 7— 13. Режим электронного доступа http://oniip.ru/upload/iblock/flа/Кирносов%20и%20др..р<1£ (Дата обращения 03 июня 2022 г.).
2. Макаренко С. И., Иванов М. С. Сетецентрическая война — принципы, технологии, примеры и перспективы. Монография. - СПб.: Наукоемкие технологии, 2018. - 898 с. Режим электронного доступа https://sccs.intelgr.com/editors/Makarenko/Makarenko_Ivanov-Netcentric_wars.pdf. (Дата обращения 02 июня 2022 г.).
3. Alessandro Finamore et al, "Experiences of Internet Traffic Monitoring with Tstat," IEEE Network, May/June 2011. Режим электронного доступа https://citeseerx.ist.psu.edu/viewdoc/download?doi= 10.1.1.720.403 5&rep=rep 1 &type=pdf. (Дата обращения 30 мая 2022 г.).
4. Dongjin Lee et al, "Media Streaming Observations: Trends in UDP to TCP Ratio," International Journal on Advances in Systems and Measurements, vol 3 no 3 & 4, 2010. Режим электронного доступа https://www.cs.auckland.ac.nz/~brian/media-UDP-TCP.pdf. (Дата обращения 30 мая 2022 г.).
5. Van Jacobson and Michael Karels, "Congestion Avoidance and Control," Proceedings of ACM SIGCOMM '88, pages 314—329, August 1988. Режим электронного доступа http://ccr.sigcomm.org/archive/1995/jan95/ccr-9501-jacobson.pdf. (Дата обращения 30 мая 2022 г.).
6. George Xylomenos et al, "TCP Performance Issues over Wireless Links," IEEE Communications Magazine, April 2001. Режим электронного доступа https://mm.aueb.gr/publications/2001-TCP-Comms.pdf. (Дата обращения 30 мая 2022 г.).
7. Performance Measurements of Applications using IP over HF Radio. Режим электронного доступа https://www.isode.com/whitepapers/peiformance-of-ip-applications-over-hf-radio.html. (Дата обращения 03 июня 2022 г.).
8. Н. Balakrishnan, S. Seshan, Е. Amir, R. Katz, "Improving TCP/IP Performance over Wireless Networks," Proc. 1st ACM Conference on Mobile Communications and Networking (Mobicom), Berkeley, California, November 1995. Режим электронного доступа https://www.researchgate.net/publication/234781455_Improving_TCPIP_performance_over_Wireless_Netw orks. (Дата обращения 08 июня 2022 г.).
9. IETF RFC 3135, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations," June 2001. Режим электронного доступа https://tools.ietf.org/html/rfc3135. (Дата обращения 27 мая 2022 г.).
10. Igor Bisio, Mario Marchese, and Maurizio Mongelli. Performance Enhanced Proxy Solutions for Satellite Networks: State of the Art, Protocol Stack and Possible Interfaces. Режим электронного доступа https://www.researchgate.net/publication/225267154_Performance_Enhanced_Proxy_Solutions_for_Satellit e_Networks_Stete_of_the_Art_Protocol_Stack_and_Possible_Interfaces/link/54a67eaa0cf257a6360977f5/do wnload (Дата обращения 06 июня 2022 г.).
11. Paul D. Wiedemeier, Clarke M. Williams. Performance Modeling of TCP and UDP over Packet Radio Networks using the ns-2 Network Simulator. Режим электронного доступа https://www.researchgate.net/publication/239840595. (Дата обращения 09 июня 2022 г.).
12. Kevin Fall, Kannan Varadhan. The Manual (formerly Notes and Documentation). The VINT Project A collaboration between researchers at UC Berkeley, LBL, USC/ISI, and Xerox PARC, Nov 5, 2011 (ns-2.35). Режим электронного доступа https://www.isi.edu/nsnam/ns/doc/node396.html. (Дата обращения 09 июня 2022 г.).
References
1. Automation of e-mail exchange in a short-wave radio channel / A. A. Kirnosov, D. A. Korzhakov, I. V. Potapov, T. R. Khairulin // Radio communication Technology. 2019. Issue 4 (43). pp. 7-13. Electronic access mode http://oniip.ru/upload/iblock/fla/KHpHocoB%20H%20flp..pdf. (03.06.2022 г.). (in Russian).
2. Makarenko S.I., Ivanov M.S. Network-centric warfare - principles, technologies, examples and prospects. Monograph. - St. Petersburg: Science-intensive technologies, 2018. - 898 p. Electronic access mode https://sccs.intelgr.com/editors/Makarenko/Makarenko_Ivanov-Netcentric_wars.pdf. (02.06.2022 г.). (in Russian).
3. Alessandro Finamore et al, "Experiences of Internet Traffic Monitoring with Tstat," IEEE Network, May/June 2011. Electronic access mode https://citeseerx.ist.psu.edu/viewdoc/download?doi= 10.1.1.720.4035&rep=rep 1 &1ype=pdf. (30.05.2022 г.).
4. Dongjin Lee et al, "Media Streaming Observations: Trends in UDP to TCP Ratio," International Journal on Advances in Systems and Measurements, vol 3 no 3 & 4, 2010. Electronic access mode https://www.cs.auckland.ac.nz/~brian/media-UDP-TCP.pdf. (30.05.2022 г.).
5. Van Jacobson and Michael Karels, "Congestion Avoidance and Control," Proceedings of ACM SIGCOMM '88, pages 314-329, August 1988. Electronic access mode http://ccr.sigcomm.org/archive/1995/jan95/ccr-9501-jacobson.pdf. (30.05.2022 г.).
6. George Xylomenos et al, "TCP Performance Issues over Wireless Links," IEEE Communications Magazine, April 2001. Electronic access mode https://mm.aueb.gr/publications/2001-TCP-Comms.pdf. (30.05.2022 г.).
7. Performance Measurements of Applications using IP over HF Radio. Electronic access mode https://www.isode.com/whitepapers/performance-of-ip-applications-over-hf-radio.html. (03.06.2022 г.).
8. H. Balakrishnan, S. Seshan, E. Amir, R. Katz, "Improving TCP/IP Performance over Wireless Networks," Proc. 1st ACM Conference on Mobile Communications and Networking (Mobicom), Berkeley, California, November 1995. Electronic access mode https://www.researchgate.net/publication/234781455_Improving_TCPIP_performance_over_Wireless_Netw orks. (08.06.2022).
9. IETF RFC 3135, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations," June 2001. Electronic access mode https://tools.ietf.org/html/rfc3135. (27.05.2022).
10. Igor Bisio, Mario Marchese, and Maurizio Mongelli. Performance Enhanced Proxy Solutions for Satellite Networks: State of the Art, Protocol Stack and Possible Interfaces. Electronic access mode https://www.researchgate.net/publication/225267154_Performance_Enhanced_Proxy_Solutions_for_Satellit eJ4etworks_State_of_1he_Art_Protocol_Stack_and_PossibleJnterfaces/link/54a67eaa0cf257a6360977f5/do wnload. (06.06.2022).
11. Paul D. Wiedemeier, Clarke M. Williams. Performance Modeling of TCP and UDP over Packet Radio Networks using the ns-2 Network Simulator. Electronic access mode https://www.researchgate.net/publication/239840595. (06.06.2022).
12. Kevin Fall, Kannan Varadhan. The Manual (formerly Notes and Documentation). The VINT Project A collaboration between researchers at UC Berkeley, LBL, USC/ISI, and Xerox PARC, Nov 5, 2011 (ns-2.35). Electronic access mode https://www.isi.edu/nsnam/ns/doc/node396.html. (09.06.2022).
Статья поступила 20 ноября 2022 г.
Информация об авторе
Молокович Игорь Аркадьевич — кандидат технических наук, доцент, ведущий инженер ПАО «Интелтех». Область научных интересов: телекоммуникационные сети; алгоритмы и протоколы маршрутизации. Тел.: +7 921-344-24-29. E-mail: igor-molokovich@yandex.ru.
Адрес: 197342, Россия, г. Санкт-Петербург, Кантемировская ул., д. 8.
Simulation of IP traffic transmission over a HF radio network using Network Simulator NS2
I. A. Molokovich
Annotation. Problem statement: the problems associated with the transmission of IP packets over HF radio networks and possible solutions are considered. The purpose of the work is to implement the developed model for transmitting IP packets over a HF radio network in the network simulator ns-2 software simulator and to conduct research on the bandwidth of the radio network. Methods used: simulation modeling using a software simulator of telecommunication networks Network Simulator (NS-2). The novelty lies in the fact that a proxy server of the transport layer is used in the implementation of the developed model of the radio communication network using the network simulator ns-2 software simulator. The result is that the bandwidth of the radio network has been investigated for various TCP segment sizes, the probability of error per bit and the transmission rate in the radio channel when using a proxy server and without it. Practical significance: the results obtained using the network simulator ns-2 software simulator allow us to determine the optimal TCP segment size in terms of bandwidth for different transmission rates and the probability of an error per bit in the radio channel when using a proxy server and without it.
Keywords: radio network, HF band, Internet Protocol, proxy server, network simulator ns-2.
Author information
Molokovich Igor Arkadievich - candidate of technical Sciences, associate Professor, leading engineer of PJSC "Inteltech". Research interests: telecommunication networks; routing algorithms and protocols. Tel: +7 921 344 24 29. E-mail: igor-molokovich@yandex.ru
Address: Russia, 197342, Saint-Petersburg, Kantemirovskay Av., 8.
Для цитирования: Молокович И. А. Моделирование передачи трафика IP по радиосети KB диапазона с помощью Network Simulator NS-2 // Техника средств связи. 2022. № 4 (160). С. 17-30. DOI: 10.24412/2782-2141-2022-4-17-30.
For citation: Molokovich I. A. Simulation of IP traffic transmission over a HF radio network using Network Simulator NS2. Means of Communication Equipment. 2022. No. 4 (160). Pp. 17-30. DOI: 10.24412/2782-2141-2022-4-17-30. (in Russian).
