ns-3-model-library - Онлайн в облаке

ПРОГРАММА:

ИМЯ

ns-3-model-library - Библиотека моделей ns-3

Это нс-3 Модель Библиотека документация. Первичная документация по проекту нс-3
доступен в пяти формах:

· нс-3 Доксиген: Документация общедоступных API симулятора.

· Учебное пособие, руководство и библиотека моделей (этот документ) для последний освободить и
способствовали дерево

· нс-3 Вики

Этот документ написан на ReStructuredText для Сфинкс и поддерживается в
документ / модели каталог исходного кода ns-3.

ОРГАНИЗАЦИЯ

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

· нс-3 программное обеспечение организовано в отдельные модули каждый из которых построен как отдельный
программная библиотека. Отдельные программы ns-3 могут связывать необходимые им модули (библиотеки)
провести их моделирование.

· нс-3 ухода являются абстрактными представлениями реальных объектов, протоколов, устройств и т. д.

An нс-3 модуль может состоять более чем из одной модели (например, интернет модуль
содержит модели как для TCP, так и для UDP). Как правило, модели NS-3 не охватывают несколько
программные модули, однако.

В этом руководстве представлена ​​документация по моделям нс-3. Он дополняет два других
источники документации по моделям:

· API модели задокументированы с точки зрения программирования с использованием Доксиген. Доксиген
для моделей нс-3 имеется on Проект Web сервер.

· В нс-3 core задокументировано в руководстве разработчика. нс-3 модели используют
возможности ядра, такие как атрибуты, значения по умолчанию, случайные числа, тест
фреймворки и т. д. Проконсультируйтесь с main Web сайте найти копии руководства.

Наконец, дополнительная документация по различным аспектам нс-3 может существовать на Проект
Вики.

Образец схемы написания документации библиотеки моделей можно найти, выполнив команду
создать-module.py программу и глядя на созданный в файле шаблон
новый модуль / документ / новый модуль.rst.

$ cd источник
$ ./create-module.py новый модуль

Остальная часть этого документа организована в алфавитном порядке по названиям модулей.

Если вы новичок в нс-3, вы можете сначала прочитать ниже о сетевом модуле, который
содержит некоторые фундаментальные модели для симулятора. Пакетная модель, модели для
различные форматы адресов и абстрактные базовые классы для таких объектов, как узлы, сети
там обсуждаются устройства, каналы, розетки и приложения.

АНИМАЦИЯ

Анимация - важный инструмент сетевого моделирования. В то время как нс-3 не содержит
инструмент графической анимации по умолчанию, в настоящее время у нас есть два способа предоставить анимацию, а именно
используя метод PyViz или метод NetAnim. Метод PyViz описан в
http://www.nsnam.org/wiki/PyViz.

Здесь мы кратко опишем метод NetAnim.

НетАним
NetAnim - это автономный исполняемый файл на основе Qt4, который использует сгенерированный файл трассировки.
во время нс-3 моделирование для отображения топологии и анимации потока пакетов между
узлы.
[image] Пример пакетной анимации на проводных каналах. UNINDENT

Кроме того, NetAnim также предоставляет полезные функции, такие как таблицы для отображения метаданных.
пакетов, как на изображении ниже
[изображение] Пример таблиц для метаданных пакетов с фильтрами протокола. UNINDENT

Способ визуализации траектории мобильного узла
[image] Пример траектории мобильного узла. UNINDENT

Способ отображения таблиц маршрутизации нескольких узлов в различные моменты времени
[Image]

Способ отображения счетчиков, связанных с несколькими узлами, в виде диаграммы или таблицы
[Image]
[Image]

Способ просмотра временной шкалы событий передачи и приема пакетов
[Image]

Методология
Класс ns3 :: AnimationInterface отвечает за создание XML-файла трассировки.
AnimationInterface использует инфраструктуру трассировки для отслеживания потоков пакетов между узлами.
AnimationInterface регистрируется как перехватчик трассировки для событий tx и rx перед
начинается симуляция. Когда пакет запланирован для передачи или приема,
вызываются соответствующие перехватчики трассировки tx и rx в AnimationInterface. Когда крючки rx
вызываются, AnimationInterface будет знать о двух конечных точках, между которыми пакет
течет, и добавляет эту информацию в файл трассировки в формате XML вместе с
соответствующие временные метки tx и rx. Формат XML будет рассмотрен в следующем разделе.
Важно отметить, что AnimationInterface записывает пакет только в том случае, если трассировка rx
крючки называются. Каждому событию tx должно соответствовать событие rx.

Загрузка НетАним
Если NetAnim еще не доступен в нс-3 пакет, который вы скачали, вы можете сделать
следующие:

Убедитесь, что вы установили mercurial. Последнюю версию NetAnim можно
загружено с помощью mercurial с помощью следующей команды:

$ hg клон http://code.nsnam.org/netanim

Здание НетАним
Предпосылки
Qt4 (4.7 и выше) требуется для сборки NetAnim. Это можно получить, используя следующие
способы:

Для дистрибутивов Debian / Ubuntu Linux:

$ apt-get установить qt4-dev-tools

Для дистрибутива на основе Red Hat / Fedora:

$ ням установить qt4
$ yum установить qt4-devel

Для Mac / OSX см. http://qt.nokia.com/downloads/

Построить шага
Для сборки NetAnim используйте следующие команды:

$ cd нетаним
$ очистить
$ qmake NetAnim.pro (для пользователей MAC: qmake -spec macx-g ++ NetAnim.pro)
Сделать $

Примечание: qmake может быть "qmake-qt4" в некоторых системах

Это должно создать исполняемый файл с именем «NetAnim» в том же каталоге:

$ ls -l НетАним
-rwxr-xr-x 1 джон джон 390395 2012 05:22 NetAnim

Применение
Использование NetAnim - это двухэтапный процесс.

Шаг 1. Создайте XML-файл трассировки анимации во время моделирования, используя
"ns3 :: AnimationInterface" в нс-3 кодовая база.

Шаг 2. Загрузите файл трассировки XML, созданный на шаге 1, с помощью автономного аниматора на основе Qt4.
по имени NetAnim.

Шаг 1: Создайте XML анимация прослеживать файл
Класс «AnimationInterface» в «src / netanim» использует базовый нс-3 проследить источники до
создать файл ASCII с отметкой времени в формате XML.

Примеры находятся в src / netanim / examples Пример:

$ ./waf -d настройка отладки --enable-examples
$ ./waf - запустить "гантель-анимация"

Вышеупомянутое создаст XML-файл dumbbell-animation.xml.

обязательное
1. Убедитесь, что wscript вашей программы включает модуль netanim. Пример такого
wscript находится в src / netanim / examples / wscript.

2. Включите заголовок [#include "ns3 / netanim-module.h"] в свою тестовую программу.

3. Добавьте выписку

AnimationInterface anim ("animation.xml"); // где "animation.xml" - любое произвольное имя файла

[для версий до ns-3.13 вы также должны использовать строку «anim.SetXMLOutput (), чтобы установить
Режим XML, а также используйте anim.StartAnimation ();]

По желанию
Следующие шаги являются необязательными, но полезными:

// Шаг 1
anim.SetMobilityPollInterval (секунды (1));

AnimationInterface по умолчанию записывает положение всех узлов каждые 250 мс. В
оператор выше устанавливает периодический интервал, с которым AnimationInterface записывает
положение всех узлов. Если ожидается, что узлы будут двигаться очень мало, полезно установить
интервал опроса высокой мобильности, чтобы избежать больших файлов XML.

// Шаг 2
anim.SetConstantPosition (Ptr <Узел> n, двойной x, двойной y);

AnimationInterface требует, чтобы были установлены позиции всех узлов. В нс-3 это сделано
установка связанной модели MobilityModel. SetConstantPosition - быстрый способ установить xy
координаты неподвижного узла.

// Шаг 3
аним.SetStartTime (Секунд(150)); и anim.SetStopTime (Секунд(150));

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

// Шаг 4
AnimationInterface anim ("animation.xml", 50000);

Использование вышеуказанного конструктора гарантирует, что каждый XML-файл трассировки анимации имеет только 50000
пакеты. Например, если AnimationInterface захватывает 150000 пакетов, используя приведенный выше
конструктор разбивает захват на 3 файла

· Animation.xml - содержит диапазон пакетов 1-50000

· Animation.xml-1 - содержит диапазон пакетов 50001-100000

· Animation.xml-2 - содержит диапазон пакетов 100001-150000

// Шаг 5
anim.EnablePacketMetadata (правда);

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

ВНИМАНИЕ! Включение этой функции приведет к увеличению размера файлов трассировки XML. Пожалуйста, не
включите эту функцию при использовании ссылок Wimax.

// Шаг 6
anim.UpdateNodeDescription (5, «Точка доступа»);

С помощью приведенного выше оператора AnimationInterface присваивает текст «Точка доступа» узлу 5.

// Шаг 7
аним.UpdateNodeSize (6, 1.5, 1.5);

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

// Шаг 8
аним.UpdateNodeCounter (89, 7, 3.4);

С помощью приведенного выше оператора AnimationInterface устанавливает счетчик с Id == 89, связанный с
с Узлом 7 со значением 3.4. Счетчик с Id 89 получается с использованием
AnimationInterface :: AddNodeCounter. Пример использования для этого находится в
src / netanim / examples / resources_demo.cc.

Шаг 2: Загрузка XML in НетАним
1. Предполагая, что NetAnim был собран, используйте команду "./NetAnim" для запуска NetAnim. Пожалуйста
просмотрите раздел «Сборка NetAnim», если NetAnim недоступен.

2. Когда NetAnim откроется, нажмите кнопку «Открыть файл» в верхнем левом углу, выберите
XML-файл, созданный на шаге 1.

3. Нажмите зеленую кнопку воспроизведения, чтобы начать анимацию.

Вот видео, иллюстрирующее это http://www.youtube.com/watch? v = tz_hUuNwFDs

Wiki
Подробные инструкции по установке NetAnim, ответы на часто задаваемые вопросы и загрузка файла трассировки XML.
(упоминалось ранее) с использованием NetAnim, пожалуйста, обратитесь: http://www.nsnam.org/wiki/NetAnim

АНТЕННА МОДУЛЬ

Дизайн документации
Обзор
Антенный модуль обеспечивает:

1. новый базовый класс (AntennaModel), который предоставляет интерфейс для моделирования
диаграмма направленности антенны;

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

АнтеннаМодель
AntennaModel использует систему координат, принятую в [Balanis] и изображенную на рисунке.
координировать система of АнтеннаМодель. Эта система получается переводом декартовой
систему координат, используемую ns-3 MobilityModel, в новую точку отсчета o, которая является
расположение антенны, а затем преобразовать координаты каждой общей точки p
пространство из декартовых координат (x, y, z) в сферические координаты (r, heta, hi).
Модель антенны не учитывает радиальную составляющую r и учитывает только угловые составляющие
(хета, привет).
Затем диаграмма направленности антенны выражается математической функцией g (heta, hi).
grightarrow thcal {R}, который возвращает усиление (в дБ) для каждого возможного направления
передача / прием. Все углы выражены в радианах.
[изображение] Система координат модели AntennaModel.UNINDENT

При условии ухода
В этом разделе мы описываем модели диаграмм направленности антенн, которые включены в
антенный модуль.

ИзотропнаяАнтеннаМодель
Эта модель диаграммы направленности антенны обеспечивает единичное усиление (0 дБ) для всех направлений.

КосинусАнтеннаМодель
Это косинусная модель, описанная в [Chunjian]: усиление антенны определяется как:

где привет_ {0}
- азимутальная ориентация антенны (т. е. ее направление максимального усиления), а
экспоненциальный

определяет желаемую ширину луча 3 дБ hi_ {3 дБ}.
Обратите внимание, что эта диаграмма направленности не зависит от угла наклона heta.

Основное отличие модели [Chunjian] от модели, реализованной в классе
CosineAntennaModel заключается в том, что только фактор элемента (т.е. то, что описано выше
формулы). Фактически, [Chunjian] также рассматривал дополнительную антенную решетку.
фактор. Причина, по которой последнее исключено, состоит в том, что мы ожидаем, что средний пользователь
захотелось бы точно указать заданную ширину луча, не добавляя множитель массива в
последний этап, который на практике изменил бы эффективную ширину луча результирующего
диаграмма направленности.

Параболическая антеннаМодель
Эта модель основана на параболическом приближении диаграммы направленности главного лепестка. Это
часто используется в контексте клеточной системы для моделирования диаграммы направленности клетки.
сектора, см., например, [R4-092042a] и [Calcev]. Усиление антенны в дБ определяется


где привет_ {0}
- азимутальная ориентация антенны (т. е. ее направление максимального усиления),
привет_ {3dB}
- ширина луча 3 дБ, а A_ {max} - максимальное затухание антенны в дБ. Примечание
что эта диаграмма направленности не зависит от угла наклона heta.

[Баланис]
CA Balanis, "Теория антенн - анализ и проектирование", Wiley, 2-е изд.

[Чуньцзян]
Ли Чуньцзян, «Эффективные диаграммы направленности антенн для трехсекторных систем WCDMA», магистр
Научная диссертация, Технологический университет Чалмерса, Гетеборг, Швеция, 2003 г.

[Кальцев]
Джордж Кальцев и Мэтт Диллон, «Управление наклоном антенны в сетях CDMA», в Proc. из
2-я Ежегодная Международная конференция по беспроводному Интернету (WICON), 2006 г.

[R4-092042a]
3GPP TSG RAN WG4 (Радио) Встреча № 51, R4-092042, Допущения моделирования и
параметры для требований FDD HeNB RF.

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

Тестирование Документация
В этом разделе мы описываем комплекты тестов, включенные в антенный модуль, которые проверяют
его правильная функциональность.

Углы
Набор модульных тестов углов проверяет правильность построения класса Angles с помощью
корректное преобразование из декартовых трехмерных координат в соответствии с доступными методами
(построение из одного вектора и из пары векторов). Для каждого метода несколько
Предусмотрены тестовые примеры, которые сравнивают значения (привет,
heta), определяемые конструктором с известными ссылочными значениями. Тест проходит, если для каждого
если значения равны эталону с точностью до 10 ^ {- 10}, что учитывает
для числовых ошибок.

ГрадусыToRadians
Набор модульных тестов градусы-радианы проверяет, что методы ГрадусыToRadians и
Радианы работают правильно, сравнивая с известными эталонными значениями в ряде
тестовые случаи. Каждый тестовый пример проходит, если сравнение равно допуску 10 ^ {- 10}
который учитывает числовые ошибки.

ИзотропнаяАнтеннаМодель
Набор модульных тестов модель изотропной антенны проверяет, что ИзотропнаяАнтеннаМодель класс
работает правильно, т.е. всегда возвращает усиление 0 дБ независимо от направления.

КосинусАнтеннаМодель
Набор модульных тестов косинус-антенна-модель проверяет, что КосинусАнтеннаМодель классные работы
должным образом. Предусмотрено несколько тестовых примеров, которые проверяют рассчитанное значение усиления антенны.
в разных направлениях и для разных значений ориентации опорное усиление
и ширина луча. Контрольное усиление рассчитывается вручную. Каждый тестовый пример проходит, если
эталонное усиление в дБ равно значению, возвращаемому КосинусАнтеннаМодель в
допуск 0.001, который учитывает приближение, сделанное для расчета
справочные значения.

Параболическая антеннаМодель
Набор модульных тестов параболическая модель антенны проверяет, что Параболическая антеннаМодель класс
работает исправно. Предусмотрено несколько тестовых примеров, которые проверяют значение усиления антенны.
рассчитанные в разных направлениях и для разных значений ориентации
максимальное затухание и ширина луча. Контрольное усиление рассчитывается вручную. Каждый тест
случай проходит, если эталонное усиление в дБ равно значению, возвращаемому
Параболическая антеннаМодель в пределах допуска 0.001, что составляет приближение
сделано для расчета исходных значений.

AD СПЕЦИАЛЬНАЯ ПО ЗАПРОСУ, ПО ТРЕБОВАНИЮ РАССТОЯНИЕ ВЕКТОР (АОДВ)

Эта модель реализует базовую спецификацию вектора расстояния Ad Hoc On-Demand.
(AODV) протокол. Реализация основана на RFC 3561.

Модель написана Еленой Бучацкой и Павлом Бойко из ИТТФ РАН и основана на
модель ns-2 AODV, разработанная группой CMU / MONARCH и оптимизированная и настроенная Самиром
Дас и Махеш Марина, Университет Цинциннати, а также о реализации AODV-UU
Эрик Нордстрём из Уппсальского университета.

Модель Описание
Исходный код модели AODV находится в каталоге SRC / AODV.

Дизайн
Класс ns3 :: aodv :: RoutingProtocol реализует весь функционал обмена служебными пакетами
и наследуется от ns3 :: Ipv4RoutingProtocol. Базовый класс определяет две виртуальные функции
для маршрутизации и пересылки пакетов. Первый, ns3 :: aodv :: RouteOutput, используется для
пакеты, исходящие локально, а второй, ns3 :: aodv :: RouteInput, используется для
пересылка и / или доставка полученных пакетов.

Работа протокола зависит от многих настраиваемых параметров. Параметры для этого
функциональность - атрибуты ns3 :: aodv :: RoutingProtocol. Значения параметра по умолчанию:
взяты из RFC и позволяют включать / отключать функции протокола, такие как
широковещательные сообщения HELLO, широковещательные пакеты данных и т. д.

AODV обнаруживает маршруты по запросу. Следовательно, модель AODV буферизует все пакеты, пока
пакет запроса маршрута (RREQ) распространяется. Очередь пакетов реализована в
aodv-rqueue.cc. Умный указатель на пакет, нс3 :: Ipv4RoutingProtocol :: ErrorCallback,
нс3 :: Ipv4RoutingProtocol :: UnicastForwardCallback, и заголовок IP хранится в этом
очередь. Очередь пакетов реализует сборку мусора старых пакетов и размер очереди
предел.

Реализация таблицы маршрутизации поддерживает сборку мусора старых записей и состояний.
машина, определенная в стандарте. Он реализован как контейнер карты STL. Ключ - это
IP-адрес получателя.

Некоторые элементы работы протокола не описаны в RFC. Эти элементы обычно
касаются взаимодействия различных уровней модели OSI. В модели используются следующие
эвристика:

· Эта реализация AODV может обнаруживать наличие однонаправленных ссылок и избегать их
если необходимо. Если узел, для которого модель получает RREQ, является соседом, причина может
быть однонаправленной ссылкой. Эта эвристика взята из реализации AODV-UU и может
быть отключенным.

· Работа протокола сильно зависит от механизма обнаружения неработающих ссылок. Модель
реализует две такие эвристики. Во-первых, эта реализация поддерживает сообщения HELLO.
Однако сообщения HELLO не являются хорошим способом определения соседей в беспроводной сети.
среды (по крайней мере, не выше 802.11). Следовательно, может возникнуть плохая работа.
при работе по беспроводной сети. Для этого есть несколько причин: 1) Сообщения HELLO передаются.
транслировался. В 802.11 широковещательная передача часто выполняется с более низкой скоростью передачи данных, чем одноадресная передача.
таким образом, сообщения HELLO могут перемещаться дальше, чем одноадресные данные. 2) Сообщения HELLO маленькие,
таким образом, менее подвержены битовым ошибкам, чем передача данных, и 3) широковещательная передача
не гарантируется, что они будут двунаправленными, в отличие от одноадресной передачи. Во-вторых, мы используем
обратная связь уровня 2, когда это возможно. Ссылка считается разорванной, если передача кадра
приводит к сбою передачи для всех повторных попыток. Этот механизм предназначен для активных
ссылки и работает быстрее, чем первый способ.

Реализация обратной связи уровня 2 основана на TxErrHeader источник трассировки, в настоящее время
поддерживается только в AdhocWifiMac.

Объем и ограничения
Модель предназначена только для IPv4. Следующие необязательные оптимизации протокола не
реализовано:

1. Расширение кольцевого поиска.

2. Ремонт локальной ссылки.

3. Расширения сообщений RREP, RREQ и HELLO.

Эти методы требуют прямого доступа к IP-заголовку, что противоречит утверждению из
AODV RFC, что AODV работает через UDP. В этой модели для простоты используется UDP, что затрудняет
возможность реализации определенных оптимизаций протокола. Модель не использует низкоуровневое сырье
розетки, потому что они непереносимы.

Будущее Рабочая
Нет анонсированных планов.

Рекомендации
Применение
Примеры
Помощники
Атрибуты
трассировка
Запись
Предостережения
Проверка
Ед. тестов
В большем масштабе производительность тестов

ПРИМЕНЕНИЕ

Заполнитель глава

МОСТ СЕТЕВОЕ УСТРОЙСТВО

Заполнитель глава

Некоторые примеры использования Bridge NetDevice можно найти в примеры / csma / каталог.

БРАЙТ ИНТЕГРАЦИЯ

Эта модель реализует интерфейс с BRITE, Интернет-представителем Бостонского университета.
Генератор топологии [1]. BRITE - это стандартный инструмент для создания реалистичного Интернета.
топологии. Модель ns-3, описанная здесь, предоставляет вспомогательный класс для облегчения
создание топологий, специфичных для ns-3, с использованием файлов конфигурации BRITE. BRITE создает
исходный граф, который хранится в виде узлов и ребер в классе ns-3 BriteTopolgyHelper. В
После интеграции BRITE ns-3 генератор генерирует топологию и затем предоставляет доступ
в листовые узлы для каждой сгенерированной AS. Пользователи ns-3 могут присоединять собственные топологии к
эти листовые узлы, создавая их вручную или используя генераторы топологии, представленные в
нс-3.

В BRITE доступны три основных типа топологий: маршрутизатор, AS и
Иерархический, который представляет собой комбинацию AS и Router. Для целей нс-3
имитация, наиболее полезными, вероятно, будут Router и Hierarchical. Уровень маршрутизатора
топологии могут быть сгенерированы с использованием модели Ваксмана или модели Барабаси-Альберта. Каждый
модель имеет различные параметры, влияющие на создание топологии. Для топологий с плоским маршрутизатором
все узлы считаются находящимися в одной AS.

BRITE Иерархические топологии содержат два уровня. Первый - это уровень AS. Этот уровень
также могут быть созданы с использованием модели Ваксмана или модели Барабаси-Альберта.
Затем для каждого узла в топологии AS строится топология уровня маршрутизатора. Эти
Топологии уровня маршрутизатора могут снова использовать модель Ваксмана или модель Барбаси-Альберта.
BRITE соединяет эти отдельные топологии маршрутизаторов в соответствии с требованиями уровня AS.
топология. После построения иерархической топологии она превращается в большую
топология на уровне маршрутизатора.

Дополнительную информацию можно найти в руководстве пользователя BRITE:
http://www.cs.bu.edu/brite/publications/usermanual.pdf

Модель Описание
Модель полагается на создание внешней библиотеки BRITE, а затем на построение некоторого ns-3.
помощники, которые взывают к библиотеке. Исходный код для помощников ns-3 находится в
каталог SRC / brite / помощник.

Дизайн
Чтобы сгенерировать топологию BRITE, помощники ns-3 обращаются к внешней библиотеке BRITE, и
используя стандартный файл конфигурации BRITE, код BRITE строит граф с узлами и
ребра в соответствии с этим файлом конфигурации. См. Документацию BRITE или
файлы конфигурации примеров в src / brite / examples / conf_files, чтобы лучше понять
Варианты конфигурации BRITE. График, построенный BRITE, возвращается в нс-3, а нс-3
реализация графа построена. Конечные узлы для каждой AS доступны пользователю.
для присоединения пользовательских топологий или непосредственной установки приложений ns-3.

Рекомендации
[1] Альберто Медина, Анукул Лакхина, Ибрагим Матта и Джон Байерс. БРАЙТ: подход к
Генерация универсальной топологии. В материалах международного семинара по
Моделирование, анализ и моделирование компьютерных и телекоммуникационных систем - MASCOTS
'01, Цинциннати, Огайо, август 2001 г.

Применение
Можно сослаться на brite-generic-example, чтобы увидеть базовое использование интерфейса BRITE. В
Таким образом, BriteTopologyHelper используется в качестве точки интерфейса, передавая BRITE
конфигурационный файл. Наряду с файлом конфигурации файл случайного начального числа в формате BRITE.
также может быть передан. Если исходный файл не передан, помощник создаст начальный файл
файл, используя UniformRandomVariable ns-3. После того, как топология была сгенерирована BRITE,
BuildBriteTopology () вызывается для создания представления ns-3. Следующий IP-адрес может быть
назначается топологии с помощью AssignIpv4Addresses () или AssignIpv6Addresses (). Это
Следует отметить, что каждое соединение точка-точка в топологии будет рассматриваться как новое
сеть, поэтому для IPV4 следует использовать подсеть / 30, чтобы избежать потери большого количества
доступное адресное пространство.

Примеры файлов конфигурации BRITE можно найти в / src / brite / examples / conf_files /.
ASBarbasi и ASWaxman являются примерами топологий только AS. RTBarabasi и RTWaxman
файлы являются примерами топологий только маршрутизатора. Наконец, TD_ASBarabasi_RTWaxman
файл конфигурации является примером иерархической топологии, в которой используется схема Барабаши-Альберта.
модель для уровня AS и модель Waxman для каждой топологии уровня маршрутизатора.
Информацию о параметрах BRITE, используемых в этих файлах, можно найти у пользователя BRITE.
руководство.

Здание БРАЙТ интеграцию
Первым шагом является загрузка и создание репозитория BRITE для ns-3:

$ hg клон http://code.nsnam.org/BRITE
$ cd БРАЙТ
Сделать $

Это соберет BRITE и создаст библиотеку libbrite.so в каталоге BRITE.

После успешной сборки BRITE мы приступаем к настройке ns-3 с поддержкой BRITE.
Перейдите в каталог ns-3:

$ ./waf configure --with-brite = / ваш / путь / к / brite / source --enable-examples

Убедитесь, что рядом с надписью «Интеграция с BRITE» написано «включено». Если нет, значит, что-то
пошло не так. Либо вы забыли сначала собрать BRITE, выполнив описанные выше шаги, либо
ns-3 не может найти ваш каталог BRITE.

Далее строим нс-3:

$ ./ваф

Примеры
Для примера, демонстрирующего запуск интеграции BRITE:

$ ./waf - выполнить 'brite-generic-example'

Если включить параметр verbose, в примере будут распечатаны узел и край.
информация в формате, аналогичном стандартному выходу BRITE. Есть много других
параметры командной строки, включая confFile, tracing и nix, описанные ниже:

confFile
Файл конфигурации BRITE. Множество различных примеров файлов конфигурации BRITE
существуют в каталоге src / brite / examples / conf_files, например,
RTBarabasi20.conf и RTWaxman.conf. Пожалуйста, обратитесь к каталогу conf_files
для большего количества примеров.

трассировка
Включает трассировку ascii.

NIX Включает nix-векторную маршрутизацию. По умолчанию используется глобальная маршрутизация.

Общий пример BRITE также поддерживает визуализацию с использованием pyviz, предполагая привязки python.
в нс-3 включены:

$ ./waf - выполнить brite-generic-example --vis

Моделирование с использованием BRITE также можно использовать с MPI. Общее количество экземпляров MPI
передается помощнику по топологии BRITE, где используется деление по модулю для назначения узлов
для каждой AS к экземпляру MPI. Пример можно найти в src / brite / examples:

$ mpirun -np 2 ./waf --run brite-MPI-пример

См. Документацию по ns-3 MPI для получения информации о настройке MPI с помощью ns-3.

ЗДАНИЯ МОДУЛЬ

cd .. include :: replace.txt

Дизайн документации
Обзор
Модуль Buildings предоставляет:

1. новый класс (Здание), который моделирует присутствие здания в симуляции.
сценарий;

2. новый класс (МобильностьСтроительствоИнфо), что позволяет указать местоположение, размер и
характеристики зданий, присутствующих в моделируемой области, и позволяет размещать
узлов внутри этих зданий;

3. контейнерный класс с определением наиболее полезных моделей потерь пути и
соответствующие переменные, называемые ЗданияРаспространениеПотериМодель.

4. новая модель распространения (Гибридные зданияРаспространениеПотериМодель) работа с
только что представленная модель мобильности, которая позволяет смоделировать феномен
внутреннее / внешнее распространение при наличии построек.

5. упрощенная модель, работающая только с Окумура Хата (OhЗданияРаспространениеПотеряМодель)
учитывая явление распространения внутри / снаружи при наличии
здания.

Модели были разработаны с учетом LTE, хотя на самом деле их реализация
не зависит от какого-либо кода, специфичного для LTE, и может использоваться с другими беспроводными сетями ns-3.
также технологии (например, Wi-Fi, WIMAX).

Команда Гибридные зданияРаспространениеПотериМодель Включенная модель потерь в траектории получена с помощью
комбинация нескольких хорошо известных моделей потерь пути для имитации различных
сценарии окружающей среды, такие как городские, пригородные и открытые территории. Более того, модель
считает, что должна быть включена как внешняя, так и внутренняя внутренняя и внешняя связь
поскольку HeNB может быть установлен как внутри здания, так и снаружи. В случае внутреннего
коммуникации, модель должна учитывать также тип здания в открытом <-> помещении
связь в соответствии с некоторыми общими критериями, такими как потери при прохождении стен
общие материалы; кроме того, он включает некоторую общую конфигурацию для внутреннего
стены во внутренних коммуникациях.

Команда OhЗданияРаспространениеПотеряМодель модель потерь пути была создана для упрощения
предыдущая снятие порогов для перехода с одной модели на другую. Для этого
была использована только одна модель распространения из доступной (т.е.
Хата). Наличие постройки по-прежнему учитывается в модели; поэтому все
вышеизложенные соображения относительно типа здания остаются в силе. Одинаковый
можно рассмотреть, что касается экологического сценария и частоты, поскольку
оба они являются параметрами рассматриваемой модели.

Команда Здание класс
Модель включает в себя определенный класс, называемый Здание который содержит ns3 Коробка класс для
определение размеров здания. Чтобы реализовать характеристики
включены модели потерь в пути, Здание class поддерживает следующие атрибуты:

· Тип здания:

· Жилой (значение по умолчанию)

· Офис

· Коммерческая

· Тип наружных стен

· Древесина

· ConcreteWithWindows (значение по умолчанию)

· Бетон без окон

· Каменные блоки

· Количество этажей (значение по умолчанию 1, что означает только цокольный этаж)

· Количество комнат по оси x (значение по умолчанию 1)

· Количество комнат по оси Y (значение по умолчанию 1)

Класс Building основан на следующих предположениях:

· Здание представлено в виде прямоугольного параллелепипеда (т.е. коробки)

· Стены параллельны осям x, y и z

· Здание разделено на сеть комнат, определяемых по следующим параметрам:

· количество этажей

· Количество комнат по оси абсцисс

· Количество комнат по оси ординат

· Ось z - вертикальная ось, т. Е. Номера этажей увеличиваются с увеличением оси z
ценности

· Индексы комнат x и y начинаются с 1 и увеличиваются по осям x и y
соответственно

· Все комнаты в здании одинакового размера

Команда МобильностьСтроительствоИнфо класс
Команда МобильностьСтроительствоИнфо класс, наследуемый от класса ns3 объект, ответственный за
сохранение информации о положении узла по отношению к зданию. В
информация управляется МобильностьСтроительствоИнфо это:

· Независимо от того, находится ли узел в помещении или на улице

· В помещении:

· В каком здании находится узел

· В каком помещении расположен узел (индексы x, y и этажа)

Класс МобильностьСтроительствоИнфо используется ЗданияРаспространениеПотериМодель класс, который
наследуется от класса ns3 Модель распространения потерь и управляет вычислением потерь пути
отдельные компоненты и их состав в соответствии с положением узлов. Кроме того,
реализует также затенение, то есть потерю из-за препятствий на основном пути
(т.е. растительность, здания и т. д.).

Следует отметить, что МобильностьСтроительствоИнфо может использоваться любой другой моделью распространения.
Однако, исходя из информации на момент написания этой статьи, только те, которые определены в
строительный модуль спроектирован с учетом ограничений, вносимых
здания.
g
ItuR1238РаспространениеПотеряМодель
Этот класс nm дополняет модель потерь при распространении внутри помещений, зависящую от здания, основанную на ITU.
P.1238 modeg {который включает потери из-за типа здания (т. Е. Жилого, офисного и
коммерческий) ia Аналитическое выражение приводится ниже.
nr
{r
aa
где: ry ight. : потеря мощности
N = tr} сидячий \ 30 и офис \ 22 и коммерческий \ nd {массив}
коэффициент [дБ]
ил свет.
L_f = t} сидячий \ 15 + 4 (n-1) и офисный \ 6 + 3 (n-1) и коммерческий \ nd {array}
{l
n: количество этажей между базовой станцией и мобильным устройством (n 1)
l2
f: частота [МГц]
}&
d: расстояние (где d> 1) [м]
n
Здания&ationLossModel
BuildingsPropagationLossModel предоставляет дополнительный набор зависимых от здания
Элементы модели потерь пути, которые используются для реализации различных логик потерь пути. Эти
Элементы модели потерь в тракте описаны в следующих подразделах.

Внешний Стена Убыток (ЭВЛ)
Этот компонент моделирует потери при прохождении через стены для внутренних и наружных работ.
коммуникации и наоборот. Значения взяты из модели [cost231].

· Дерево ~ 4 дБ

· Бетон с окнами (неметаллизированный) ~ 7 дБ

· Бетон без окон ~ 15 дБ (диапазон от 10 до 20 по COST231)

· Брусчатка ~ 12 дБ

внутренний Стены Убыток (ИВЛ)
Этот компонент моделирует потери проникновения, возникающие при передаче данных между помещениями.
в том же здании. Общие потери рассчитываются исходя из того, что каждая отдельная внутренняя
стена имеет постоянные потери при прохождении через L_ {siw}, и приблизительно количество стен, которые
преодолеваются манхэттенским расстоянием (в количестве комнат) между передатчиками
и ресивер. Более подробно, пусть x_1, y_1, x_2, y_2 обозначают номер комнаты вдоль x и
ось y соответственно для пользователя 1 и 2; общие потери L_ {IWL} рассчитываются как

Высота Gain Модель (ХГ)
Этот компонент моделирует усиление из-за того, что передающее устройство находится на полу.
выше земли. В [turkmani] литературе это усиление оценивается примерно в 2 дБ.
за этаж. Это усиление может применяться ко всем внутренним и внешним коммуникациям и
наоборот.

слежка Модель
Затенение моделируется в соответствии с логнормальным распределением с переменным стандартом.
отклонение как функция относительного положения (внутри или снаружи) MobilityModel
вовлеченные экземпляры. Одно случайное значение отображается для каждой пары моделей мобильности и остается
константа для этой пары в течение всего моделирования. Таким образом, модель подходит для
только статические узлы.

Модель считает, что среднее значение потерь на затенение в дБ всегда равно 0. Для
дисперсии, модель подробно рассматривает три возможных значения стандартного отклонения:
ightarrow X_thrm {O}
· Открытый (m_shadowingSigmaOutdoor, значение по умолчанию 7 дБ)
N (_thrm {O}, ma_thrm {O} ^ 2).
ightarrow X_thrm {I}
· в помещении (m_shadowingSigmaIndoor, значение по умолчанию 10 дБ)
N (_thrm {I}, ma_thrm {I} ^ 2).
стрелка
· Проникновение в наружные стены (m_shadowingSigmaExtWalls, значение по умолчанию 5 дБ)
X_thrm {W} N (_thrm {W}, ma_thrm {W} ^ 2)

Симулятор генерирует значение затенения для каждого активного канала в соответствии с узлами.
позиция в первый раз, когда ссылка используется для передачи. В случае передачи от
внешние узлы к внутренним, и наоборот, стандартное отклонение (ma_thrm {IO}) должно быть
рассчитывается как квадратный корень из суммы квадратичных значений стандартной
отклонение при наружных узлах и одно при прохождении наружных стен. Это
из-за того, что компоненты, производящие затенение, не зависят от каждого
Другие; следовательно, дисперсия распределения, полученная в результате суммы двух независимых
нормальные - это сумма отклонений.

Патлосс логика
Далее мы описываем различную логику потери пути, которая реализуется
наследуется от BuildingsPropagationLossModel.

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

· OkumuraHataPropagationLossModel (OH) (на частотах> 2.3 ГГц заменено на
Kun2600MhzPropagationLossModel)

· ItuR1411LosPropagationLossModel и ItuR1411NlosOverRooftopPropagationLossModel
(И1411)

· ItuR1238Модель потерь при распространении (I1238)

· Элементы потерь пути BuildingsPropagationLossModel (EWL, HG, IWL)

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

если (txNode находится вне помещения)
тогда
если (rxNode находится вне помещения)
тогда
если (расстояние> 1 км)
тогда
если (rxNode или txNode находится ниже крыши)
тогда
Л = I1411
еще
L = ОН
еще
Л = I1411
еще (rxNode находится в помещении)
если (расстояние> 1 км)
тогда
если (rxNode или txNode находится ниже крыши)
L = I1411 + EWL + HG
еще
L = ОН + EWL + HG
еще
L = I1411 + EWL + HG
еще (txNode находится в помещении)
если (rxNode находится в помещении)
тогда
если (то же здание)
тогда
L = I1238 + ИВЛ
еще
L = I1411 + 2 * EWL
еще (rxNode находится на открытом воздухе)
если (расстояние> 1 км)
тогда
если (rxNode или txNode находится ниже крыши)
тогда
L = I1411 + EWL + HG
еще
L = ОН + EWL + HG
еще
L = I1411 + ЭВЛ

Отметим, что в случае связи между двумя узлами ниже уровня крыши с
расстояние больше 1 км, мы по-прежнему рассматриваем модель I1411, так как OH специально
разработан для макроячеек и, следовательно, для антенн выше уровня крыш.

Для модели ITU-R P.1411 мы рассматриваем версии как LOS, так и NLoS. В частности, мы
учитывает распространение LoS для расстояний, которые меньше настраиваемого порога
(m_itu1411NlosПорог). В случае распространения NLoS модель над крышей будет
принимается во внимание при моделировании как макроса BS, так и SC. Если на NLoS несколько
включены параметры, зависящие от сценария, такие как средняя ширина улицы,
ориентация и т. д. Значения таких параметров должны быть правильно установлены в соответствии с
Если сценарий реализован, модель не рассчитывает их значения изначально. В случае каких-либо
приведены значения, используются стандартные, кроме высоты мобиля и БС,
вместо этого их целостность проверяется непосредственно в коде (т. е. они должны быть
больше нуля). Ниже мы приводим выражения компонентов
модели.

Также отметим, что использование разных моделей распространения (OH, I1411, I1238 с их
варианты) в HybridBuildingsPropagationLossModel может привести к разрывам
потери в пути по отношению к расстоянию. Правильная настройка атрибутов (особенно
атрибуты пороговых значений расстояния) могут избежать этих разрывов. Однако поскольку
поведение каждой модели зависит от нескольких других параметров (частота, высота узла и т. д.),
у этих порогов нет значения по умолчанию, которое могло бы избежать разрывов во всех
возможные конфигурации. Следовательно, соответствующая настройка этих параметров оставлена ​​на усмотрение
пользователь.

OhЗданияРаспространениеПотеряМодель
Команда OhЗданияРаспространениеПотеряМодель класс был создан как простое средство для решения
проблемы прерывности Гибридные зданияРаспространениеПотериМодель не делая
настройка параметров для конкретного сценария. Решение состоит в том, чтобы использовать только одну потерю распространения.
модели (т.е. Окумура Хата), сохраняя структуру логики потерь пути для
расчет других составляющих потерь на трассе (например, потерь от проникновения через стену). Результат
модель без разрывов (кроме стенок), но менее
реалистично в целом для общего сценария со зданиями и пользователями вне / внутри помещений, например,
потому что Окумура Хата не подходит ни для внутренней коммуникации, ни для наружной
коммуникации ниже уровня крыши.

Подробно класс OhЗданияРаспространениеПотеряМодель объединяет следующие потери пути
модели:

· ОкумураХатаПропагацияЛоссМодель (Огайо)

· Элементы потерь пути BuildingsPropagationLossModel (EWL, HG, IWL)

Следующий псевдокод иллюстрирует, как описываются различные элементы модели потерь пути.
выше интегрированы в OhЗданияРаспространениеПотеряМодель:

если (txNode находится вне помещения)
тогда
если (rxNode находится вне помещения)
тогда
L = ОН
еще (rxNode находится в помещении)
Л = ОН + ЭВЛ
еще (txNode находится в помещении)
если (rxNode находится в помещении)
тогда
если (то же здание)
тогда
Л = ОН + ИВЛ
еще
L = OH + 2 * EWL
еще (rxNode находится на открытом воздухе)
Л = ОН + ЭВЛ

Отметим, что OhBuildingsPropagationLossModel является значительным упрощением в отношении
в HybridBuildingsPropagationLossModel из-за того, что всегда используется OH. Пока это
дает менее точную модель в некоторых сценариях (особенно под крышей и в помещении), она
эффективно устраняет проблему разрывов потерь, влияющих на
Гибридбилдингспропагатионлоссмодель.

Информация о пользователе Документация
Как в используют зданий in a моделирование
В этом разделе мы объясняем базовое использование модели зданий в симуляции.
программу.

Включают Заголовки
Добавьте это в начало вашей программы моделирования:

#включают

Создавай a building
В качестве примера создадим жилой дом размером 10 x 20 x 10:

двойной x_min = 0.0;
двойной x_max = 10.0;
двойной y_min = 0.0;
двойной y_max = 20.0;
двойной z_min = 0.0;
двойной z_max = 10.0;
Ptr b = CreateObject ();
b-> SetBoundaries (Box (x_min, x_max, y_min, y_max, z_min, z_max));
b-> SetBuildingType (Здание :: Жилой);
b-> SetExtWallsType (Здание :: ConcreteWithWindows);
б-> SetNFloors (3);
b-> SetNRoomsX (3);
b-> SetNRoomsY (2);

Это трехэтажное здание и внутренняя сетка 3х2 комнат равного размера.

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

Ptr gridBuildingAllocator;
gridBuildingAllocator = CreateObject ();
gridBuildingAllocator-> SetAttribute ("GridWidth", UintegerValue (3));
gridBuildingAllocator-> SetAttribute ("ДлинаX", DoubleValue (7));
gridBuildingAllocator-> SetAttribute ("LengthY", DoubleValue (13));
gridBuildingAllocator-> SetAttribute ("DeltaX", DoubleValue (3));
gridBuildingAllocator-> SetAttribute ("DeltaY", DoubleValue (3));
gridBuildingAllocator-> SetAttribute ("Высота", DoubleValue (6));
gridBuildingAllocator-> SetBuildingAttribute ("NRoomsX", UintegerValue (2));
gridBuildingAllocator-> SetBuildingAttribute ("NRoomsY", UintegerValue (4));
gridBuildingAllocator-> SetBuildingAttribute ("NFloors", UintegerValue (2));
gridBuildingAllocator-> SetAttribute ("MinX", DoubleValue (0));
gridBuildingAllocator-> SetAttribute ("MinY", DoubleValue (0));
gridBuildingAllocator-> Создать (6);

Это создаст сетку 3x2 из 6 зданий, каждое 7 x 13 x 6 м с 2 x 4 комнатами внутри и
2 этажа; здания расположены на расстоянии 3 м как по оси x, так и по оси y.

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

MobilityHelper мобильность;
мобильность.SetMobilityModel ("ns3 :: ConstantPositionMobilityModel");
ueNodes.Создать (2);
мобильность.Установить (ueNodes);
BuildingsHelper :: Установить (ueNodes);

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

Место некоторых узлы
Вы можете разместить узлы в симуляции, используя несколько методов, которые описаны в
следующий.

Наследие позиционирование методы
Любой устаревший метод позиционирования ns-3 может использоваться для размещения узла в моделировании. В
Важным дополнительным шагом является: Например, вы можете разместить узлы вручную следующим образом:

Ptr mm0 = enbNodes.Get (0) -> GetObject ();
Ptr mm1 = enbNodes.Get (1) -> GetObject ();
mm0-> SetPosition (Vector (5.0, 5.0, 1.5));
mm1-> SetPosition (Vector (30.0, 40.0, 1.5));

MobilityHelper мобильность;
мобильность.SetMobilityModel ("ns3 :: ConstantPositionMobilityModel");
ueNodes.Создать (2);
мобильность.Установить (ueNodes);
BuildingsHelper :: Установить (ueNodes);
mm0-> SetPosition (Vector (5.0, 5.0, 1.5));
mm1-> SetPosition (Vector (30.0, 40.0, 1.5));

В качестве альтернативы вы можете использовать любой существующий класс PositionAllocator. Координаты
узел определит, будет ли он размещен на открытом воздухе или в помещении, и, если он находится в помещении, в каком
здание и комната размещена.

Зависит от здания позиционирование методы
Следующие классы распределителей позиций доступны для размещения узла в специальных позициях.
в отношении зданий:

· Случайное зданиеPositionAllocator: Распределите каждую позицию, случайным образом выбирая
здание из списка всех зданий, а затем случайный выбор позиции внутри
здание.

· RandomRoomPositionРаспределитель: Распределите каждую позицию, случайным образом выбирая комнату из
список комнат во всех зданиях, а затем случайный выбор позиции внутри
номер.

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

· Распределитель фиксированной комнаты: Создание случайной позиции, равномерно распределенной в
объем выбранного помещения внутри выбранного дома.

MAKE Мобильность Модель Последовательный
Важнo: всякий раз, когда вы используете здания, вы должны ввести следующую команду после того, как мы
поместили все узлы и здания в симуляцию:

BuildingsHelper :: MakeMobilityModelConsistent ();

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

Зная о зданиях потеря пути модель
После того, как вы разместили здания и узлы в моделировании, вы можете использовать
модель потерь в пути в симуляции точно так же, как вы использовали бы любые обычные потери в пути
модель. Как это сделать, зависит от рассматриваемого беспроводного модуля (lte,
Wi-Fi, wimax и т. д.), поэтому, пожалуйста, обратитесь к документации этой модели для конкретных
инструкциями.

Главная конфигурируемый Атрибуты
Команда Здание класс имеет следующие настраиваемые параметры:

· Тип здания: Жилое, Офисное, Коммерческое.

· Тип внешних стен: Дерево, Бетон с окнами, Бетон без окон и Каменные блоки.

· Границы застройки: а Коробка класс с границами здания.

· количество этажей.

· Количество комнат по оси X и Y (комнаты можно размещать только в виде сетки).

Команда ЗданиеПодвижностьПотеряМодель параметр, настраиваемый с помощью системы атрибутов ns3:
представлен связью (строка Bounds) области моделирования, предоставив Коробка класс
с границами площади. Кроме того, с помощью его методов можно определить следующие параметры:
настроено:

· Номер этажа, на котором размещен узел (по умолчанию 0).

· Положение в сетке комнат.

Команда ЗданиеРаспространениеПотериМодель класс имеет следующие настраиваемые параметры
настраивается с помощью системы атрибутов:

· частота: эталонная частота (по умолчанию 2160 МГц), обратите внимание, что при установке частоты
длина волны устанавливается соответственно автоматически и наоборот).

· Лямбда: длина волны (0.139 метра с учетом указанной выше частоты).

· ТеньСигма: стандартное отклонение затенения для внешних узлов (по умолчанию
7.0).

· ТеньСигма: стандартное отклонение затенения для внутренних узлов (по умолчанию
8.0).

· ТеньSigmaExtWalls: стандартное отклонение затенения из-за внешних стен
проникновение для наружной и внутренней связи (по умолчанию 5.0).

· КрышаУровень: уровень крыши здания в метрах (по умолчанию 20 метров).

· Лос2НлосТр: значение расстояния точки переключения между линией видимости и
модель распространения вне прямой видимости в метрах (по умолчанию 200 метров).

· ITU1411DistanceThr: значение расстояния точки переключения между коротким диапазоном
(ITU 1211) связь и дальность (Окумура Хата) в метрах (по умолчанию 200 метров).

· Минимальное расстояние: минимальное расстояние в метрах между двумя узлами для оценки
потери в пути (считаются незначительными до этого порога) (по умолчанию 0.5 метра).

· Окружающая среда: сценарий среды для городских, субурбанистических и открытых территорий (по умолчанию
Городской).

· ГородРазмер: размер города: малый, средний, большой (по умолчанию Большой).

Чтобы использовать гибридный режим, необходимо использовать класс
ГибридСтроительствоМобильностьПотеряМодель, что позволяет выбрать подходящую модель потерь в пути
в соответствии с логикой потерь пути, представленной в главе о проектировании. Однако это решение
имеет проблему, заключающуюся в том, что точки переключения модели потерь на пути следования могут иметь разрывы из-за
к разным характеристикам модели. Это означает, что в соответствии с конкретным
В этом случае необходимо правильно настроить порог переключения. Простой
ОЗданиеМобильностьПотеряМодель преодолеть эту проблему, используя только модель Окумура Хата и
потери при проходке стен.

Тестирование Документация
Обзор
Для тестирования и проверки модуля NS-3 Building Pathloss предоставляются некоторые наборы тестов, которые
интегрированы с тестовой платформой ns-3. Для их запуска вам необходимо настроить
построить симулятор таким образом:

$ ./waf configure --enable-tests --enable-modules = Buildings
$ ./test.py

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

Получить более подробный отчет в формате HTML можно так:

$ ./test.py -w результаты.html

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

Вы можете запустить каждый набор тестов отдельно, используя эту команду:

$ ./test.py -s имя-набора-тестов

Для получения дополнительной информации о test.py и фреймворк для тестирования ns-3, пожалуйста, обратитесь к ns-3
руководство.

Описание of тест люкс
ЗданияПомощник тест
Набор тестов строительный помощник проверяет, что метод
BuildingsHelper :: MakeAllInstancesConsistent () работает правильно, т. е. что
BuildingsHelper успешно определяет, являются ли узлы наружными или внутренними, а также закрытыми.
что они расположены в правильном здании, помещении и этаже. Несколько тестовых примеров
обеспечены разными зданиями (разного размера, расположения, комнат и этажей) и
разные положения узлов. Тест проходит, если каждый узел расположен правильно.

ЗданиеПозицияАллокатор тест
Набор тестов Построение-Распределитель есть два тестовых примера, которые проверяют, что
соответственно, RandomRoomPositionAllocator и SameRoomPositionAllocator работают правильно. Каждый
тестовые примеры включают в себя одно здание 2x3x2 комнаты (всего 12 комнат) с известными координатами и
соответственно 24 и 48 узлов. Оба теста проверяют, что количество узлов, выделенных в каждом
комната является ожидаемой, и что положение узлов также правильное.

Здания Патлосс тестов
Набор тестов модель здания предоставляет различные модульные тесты, которые сравнивают
ожидаемые результаты модуля потерь пути в зданиях в конкретных сценариях с предварительными
расчетные значения, полученные в автономном режиме с помощью скрипта Octave
(тест / ссылка / здания-pathloss.m). Тесты считаются пройденными, если два значения
равны с точностью до 0.1, что считается подходящим для типичного использования
значения потерь в тракте (в дБ).

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

Тест #1 Окумара Ошибка
В этом тесте мы тестируем стандартную модель Окумура Хата; поэтому и eNB, и UE размещаются
снаружи на расстоянии 2000 м. Используемая частота - это полоса № 5 E-UTRA, которая
соответствуют 869 МГц (см. таблицу 5.5-1 из 36.101). Тест включает также проверку
расширения территорий (например, городских, пригородных и открытых территорий) и размера города
(маленький, средний и большой).

Тест #2 СТОИМОСТЬ231 Модель
Этот тест направлен на проверку модели COST231. Тест аналогичен Окумуре.
Hata one, за исключением того, что используется частота EUTRA # 1 (2140 МГц) и что тест
может выполняться только для больших и малых городов в городских сценариях из-за модели
ограничения.

Тест #3 2.6 ГГц модель
Этот тест подтверждает модель Куна с частотой 2.6 ГГц. Тест аналогичен тесту Окумура Хата, за исключением
что частота соответствует диапазону № 7 EUTRA (2620 МГц), и испытание можно проводить только в
городской сценарий.

Тест #4 МСЭ1411 LoS модель
Этот тест направлен на проверку модели ITU1411 в случае прямой видимости в пределах улицы.
каньоны передачи. В этом случае UE размещается на расстоянии 100 метров от eNB, поскольку
порог переключения между LoS и NLoS оставлен равным значению по умолчанию (т. е. 200 м).

Тест #5 МСЭ1411 NLoS модель
Этот тест направлен на проверку модели ITU1411 в случае отсутствия прямой видимости над
трансмиссии на крыше. В этом случае UE размещается на расстоянии 900 метров от eNB, в
чтобы быть выше порога переключения между LoS и NLoS, оставлено значение по умолчанию
(т.е. 200 м.).

Тест #6 ИТУП1238 модель
Этот тест направлен на проверку модели ITUP1238 в случае передачи внутри помещения. В
в этом случае и UE, и eNB размещаются в жилом доме со стенами из
бетон с окнами. УЭ находится на втором этаже и находится на расстоянии 30 метров от
eNB, который находится на первом этаже.

Тест #7 Уличный текстиль -> В помещении Окумара Ошибка модель
Этот тест подтверждает передачу сигналов от наружного к внутреннему на большие расстояния. В этом случае
УП размещается в жилом доме со стеной из бетона с окнами и
расстояния 2000 метров от внешнего eNB.

Тест #8 Уличный текстиль -> В помещении МСЭ1411 модель
Этот тест проверяет передачу сигналов от наружного к внутреннему на короткие расстояния. В этом случае
УП размещается в жилом доме со стенами из бетона с окнами и
расстояния 100 метров от внешнего eNB.

Тест #9 В помещении -> Уличный текстиль МСЭ1411 модель
Этот тест проверяет передачу сигналов от наружного к внутреннему на очень короткие расстояния. В этом
в случае размещения eNB на втором этаже жилого дома со стенами из
бетон с окнами и на расстоянии 100 метров от наружного UE (т. е. LoS
коммуникация). Следовательно, прирост высоты должен быть включен в оценку потерь пути.

Тест #10 В помещении -> Уличный текстиль МСЭ1411 модель
Этот тест проверяет передачу сигналов от наружного к внутреннему на короткие расстояния. В этом случае
eNB размещается на втором этаже жилого дома со стенами из
бетон с окнами и на расстоянии 500 метров от наружного UE (т. е. NLoS
коммуникация). Следовательно, прирост высоты должен быть включен в оценку потерь пути.

Здания слежка Тест
Набор тестов здания-затенение-тест модульный тест, предназначенный для проверки статистических
распространение модели затенения, реализованной Здания. Слежка
моделируется согласно нормальному распределению со средним значением = 0 и переменным стандартом
отклонение ma, согласно моделям, обычно используемым в литературе. Три тестовых примера:
предусмотрены, которые охватывают случаи внутренней, внешней и внутренней связи.
Каждый тестовый пример генерирует 1000 различных образцов затенения для разных пар
Экземпляры MobilityModel в заданном сценарии. Значения затенения получаются вычитанием
от общей суммы убытков, возвращенной ГибридЗданияПатлоссМодель компонент потерь на трассе
который является постоянным и предварительно определенным для каждого тестового примера. Тест подтверждает, что образец
среднее и выборочная дисперсия значений затенения попадают в доверительный интервал 99%
выборочного среднего и выборочной дисперсии. Тест также подтверждает, что значения затенения
, возвращаемый последовательно для одной и той же пары экземпляров MobilityModel, является постоянным.

Рекомендации
[туркмани]
Туркмани А.М., Дж. Д. Парсон и Д. Г. Льюис, "Распространение радиоволн в зданиях на
441, 900 и 1400 МГц », в материалах 4-й Международной конференции по наземной подвижной радиосвязи, 1987 г.

CLICK MODULAR Маршрутизатор ИНТЕГРАЦИЯ

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

Модель Описание
Исходный код модели Click находится в каталоге src / щелчок.

Дизайн
Дизайн ns-3 хорошо подходит для интеграции с Click по следующим причинам:

· Пакеты в ns-3 сериализуются / десериализуются при перемещении вверх / вниз по стеку. Это позволяет
ns-3 пакетов, которые будут передаваться в Click и от него, как есть.

· Это также означает, что любой генератор трафика и транспорт нс-3 должны работать легко.
поверх Click.

· Стремясь реализовать щелчок как экземпляр Ipv4RoutingProtocol, мы можем избежать
существенные изменения на уровне LL и MAC кода ns-3.

Целью разработки было сделать общедоступный API ns-3-click достаточно простым, чтобы пользователь
нужно просто добавить экземпляр Ipv4ClickRouting к узлу и проинформировать каждый узел Click
файла конфигурации Click (файл .click), который он должен использовать.

Эта модель реализует интерфейс для модульного маршрутизатора Click и предоставляет
Ipv4ClickRouting, чтобы разрешить узлу использовать Click для внешней маршрутизации. В отличие от нормального
Подтипы Ipv4RoutingProtocol, Ipv4ClickRouting не использует метод RouteInput (), но
вместо этого получает пакет на соответствующий интерфейс и обрабатывает его соответствующим образом. Примечание
что вам необходимо иметь элемент типа таблицы маршрутизации в графике кликов, чтобы использовать клик для
внешняя маршрутизация. Это необходимо для функции RouteOutput (), унаследованной от
Ipv4RoutingProtocol. Кроме того, узел на основе Click использует другой тип L3 в
форма Ipv4L3ClickProtocol, которая является урезанной версией Ipv4L3Protocol.
Ipv4L3ClickProtocol передает пакеты, проходящие через стек, в Ipv4ClickRouting для
обработка.

Развивающийся a Симулятор API в позволять нс-3 в взаимодействовать Нажмите
Большая часть API уже четко определена, что позволяет Click получать информацию из
симулятор (например, идентификатор узла, идентификатор интерфейса и т. д.). Сохраняя большую часть
методы, должна быть возможность писать новые реализации, специфичные для ns-3, для тех же
функциональность.

Следовательно, для интеграции Click с ns-3 класс с именем Ipv4ClickRouting будет обрабатывать
взаимодействие с Click. Код для того же можно найти в
src / click / model / ipv4-click-routing. {cc, h}.

пакет рука от между нс-3 и Нажмите
Существует четыре типа передачи пакетов, которые могут происходить между ns-3 и Click.

· L4 - L3

· L3 - L4

· L3 - L2

· L2 - L3

Чтобы преодолеть это, мы реализуем Ipv4L3ClickProtocol, урезанную версию
Ipv4L3Protocol. Ipv4L3ClickProtocol передает пакеты в и из Ipv4ClickRouting
правильно выполнить маршрутизацию.

Объем и ограничения
· В текущем состоянии NS-3 Click Integration можно использовать только с L3, оставляя
NS-3 для обработки L2. В настоящее время мы также работаем над добавлением поддержки Click MAC. Увидеть
раздел использования, чтобы убедиться, что вы соответствующим образом проектируете свои графики кликов.

· Более того, ns-3-click будет работать только с элементами уровня пользователя. Полный список
элементы доступны на http://read.cs.ucla.edu/click/elements. Элементы, которые имеют
Могут использоваться указанные рядом с ними слова «all», «userlevel» или «ns».

· На данный момент интерфейс ns-3 для Click поддерживает только протокол IPv4. Мы добавим поддержку IPv6 в
будущее.

Рекомендации
· Эдди Колер, Роберт Моррис, Бенджи Чен, Джон Джаннотти и М. Франс Каашук. В
щелкните модульный маршрутизатор. ACM-транзакции в компьютерных системах 18(3), август 2000 г., стр.
263-297.

· Лалит Суреш П. и Рубен Мерц. Ns-3-click: нажмите интеграцию модульного маршрутизатора для ns-3.
В Proc. 3-го Международного семинара ИККТ по ​​NS-3 (WNS3), Барселона, Испания. Март,
2011. Воспользуйтесь функционалом

· Майкл Нойфельд, Ашиш Джайн и Дирк Грюнвальд. Nsclick: моделирование мостовой сети
и развертывание. MSWiM '02: Материалы 5-го международного семинара ACM по моделированию
анализ и моделирование беспроводных и мобильных систем, 2002, Атланта, Джорджия, США.
http://doi.acm.org/10.1145/570758.570772

Применение
Здание Нажмите
Первый шаг - клонировать Click из репозитория github и собрать его:

$ git клон https://github.com/kohler/click
$ cd click /
$ ./configure --disable-linuxmodule --enable-nsclick --enable-wifi
Сделать $

Флаг --enable-wifi можно пропустить, если вы не собираетесь использовать Click with Wifi. *
Примечание: вам не нужно выполнять «make install».

После успешной сборки Click перейдите в каталог ns-3 и настройте ns-3.
с поддержкой Click Integration:

$ ./waf configure --enable-examples --enable-tests --with-nsclick = / path / to / click / source

Подсказка: если вы установили один каталог выше ns-3 (например, в ns-3-allinone
каталог), а имя каталога - 'click' (или символическая ссылка на каталог
называется 'click'), то спецификатор --with-nsclick не нужен; сборка нс-3
система успешно найдет каталог.

Если рядом с «NS-3 Click Integration Support» написано «включено», то все готово.
Примечание: при использовании модульного ns-3 минимальный набор модулей, необходимый для запуска всех ns-3-click
примеры - Wi-Fi, CSMA и config-store.

Затем попробуйте запустить один из примеров:

$ ./waf - запустить nsclick-simple-lan

Затем вы можете просмотреть получившиеся трассировки .pcap, которые называются nsclick-simple-lan-0-0.pcap.
и nsclick-simple-lan-0-1.pcap.

Нажмите График инструкции
При построении графика кликов следует учитывать следующее:

· Могут использоваться только элементы уровня пользователя.

· Вам нужно будет заменить элементы FromDevice и ToDevice на FromSimDevice и
Элементы ToSimDevice.

· Пакеты в ядро ​​отправляются с помощью ToSimDevice (tap0, IP).

· Для любого узла устройство, которое отправляет / принимает пакеты в / от ядра, называется
'tap0'. Остальные интерфейсы должны называться eth0, eth1 и т. Д. (Даже если вы
используя Wi-Fi). Обратите внимание, что нумерация устройств должна начинаться с 0. В дальнейшем это
будут сделаны гибкими, чтобы пользователи могли называть устройства в своих файлах Click по своему усмотрению.

· Элемент таблицы маршрутизации является обязательным. Выходные порты элемента таблицы маршрутизации должны
соответствуют номеру интерфейса устройства, через которое пакет будет
в конечном итоге будут разосланы. Нарушение этого правила приведет к действительно странной трассировке пакетов.
Затем имя этого элемента таблицы маршрутизации следует передать протоколу Ipv4ClickRouting.
объект как параметр моделирования. См. Подробности в примерах Click.

· Текущая реализация оставляет Click в основном с функциональностью L3, с обработкой ns-3
L2. Вскоре мы начнем работать над поддержкой использования протоколов MAC и в Click.
Это означает, что на данный момент элементы, специфичные для Wi-Fi Click, не могут использоваться с ns-3.

Отладка пакет Потоки от Нажмите
В любой точке графика кликов вы можете использовать кнопку «Печать» (-
http://read.cs.ucla.edu/click/elements/print) и его варианты для красивой печати
содержимого пакета. Кроме того, вы можете генерировать следы pcap пакетов, проходящих через
Щелкните график с помощью ToDump (http://read.cs.ucla.edu/click/elements/todump) элемент как
хорошо. Например:

Myarpquerier
-> Печать (fromarpquery, 64)
-> ToDump (out_arpquery, PER_NODE 1)
-> ethout;

и ... распечатает содержимое пакетов, выходящих из ArpQuerier, а затем сгенерирует
файл трассировки pcap с суффиксом out_arpquery для каждого узла, использующего кнопку Click
file, прежде чем отправлять пакеты в ethout.

Помощник
Чтобы узел запускал Click, самым простым способом было бы использовать ClickInternetStackHelper
class в вашем сценарии моделирования. Например:

ClickInternetStackHelper клик;
click.SetClickFile (myNodeContainer, «nsclick-simple-lan.click»);
click.SetRoutingTableElement (myNodeContainer, «u / rt»);
щелкните.Установить (myNodeContainer);

Примеры скриптов внутри src / щелкните / примеры / продемонстрировать использование узлов на основе Click в
разные сценарии. Источник помощника можно найти внутри
src / click / helper / click-internet-stack-helper. {h, cc}

Примеры
Были написаны следующие примеры, которые можно найти в src / щелкните / примеры /:

· Nsclick-simple-lan.cc и nsclick-raw-wlan.cc: узел на основе щелчка, взаимодействующий с
нормальный узел ns-3 без Click, используя Csma и Wifi соответственно. Это также демонстрирует
использование TCP поверх Click, что в оригинальной реализации nsclick для
НС-2 добиться не удалось.

· Nsclick-udp-client-server-csma.cc и nsclick-udp-client-server-wifi.cc: 3-узловая локальная сеть
(Csma и Wifi соответственно), при этом узлы на основе 2 Click запускают клиент UDP, который отправляет
пакеты к третьему узлу на основе Click, на котором запущен UDP-сервер.

· Nsclick-routing.cc: узел на основе One Click связывается с другим через третий узел, который
действует как IP-маршрутизатор (используя конфигурацию IP-маршрутизатора Click). Это демонстрирует
маршрутизация с помощью Click.

Скрипты доступны в / conf / которые позволяют создавать файлы Click для
несколько распространенных сценариев. IP-маршрутизатор, используемый в nsclick-routing.cc был создан из
make-ip-conf.pl и немного адаптирован для работы с ns-3-click.

Проверка
Эта модель была протестирована следующим образом:

· Модульные тесты были написаны для проверки внутреннего устройства Ipv4ClickRouting. Это может быть
найти в SRC / клик / ipv4-click-routing-test.cc. Эти тесты проверяют, подходят ли методы
внутри Ipv4ClickRouting, который обрабатывает имя устройства для идентификатора, IP-адрес из имени устройства
и Mac-адрес из привязок имен устройств работают должным образом.

· Примеры использовались для тестирования Click с реальными сценариями моделирования. Это может быть
найти в src / щелкните / примеры /. Эти тесты охватывают следующее: использование различных
виды транспорта поверх Click, TCP / UDP, могут ли узлы Click связываться с
узлы, не основанные на Click, могут ли узлы Click взаимодействовать друг с другом, используя Click
для маршрутизации пакетов с использованием статической маршрутизации.

· Click был протестирован с устройствами Csma, Wi-Fi и точка-точка. Инструкции по использованию
доступно в предыдущем разделе.

CSMA СЕТЕВОЕ УСТРОЙСТВО

Это введение в главу CSMA NetDevice, дополняющую модель doxygen Csma.

Обзор of CSMA модель
Команда нс-3 Устройство CSMA моделирует простую шинную сеть в духе Ethernet. Хотя это
не моделирует какую-либо реальную физическую сеть, которую вы могли бы когда-либо построить или купить, она предоставляет некоторые
очень полезный функционал.

Обычно, когда речь идет о шинной сети, на ум приходит Ethernet или IEEE 802.3. Ethernet
использует CSMA / CD (множественный доступ с контролем несущей и обнаружением коллизий с экспоненциально
увеличение отсрочки для борьбы за совместно используемую среду передачи. В нс-3 Устройство CSMA
моделирует только часть этого процесса, используя природу глобально доступного канала
для обеспечения мгновенного (быстрее скорости света) определения несущей и коллизии на основе приоритета
«избегание». Коллизий в смысле Ethernet никогда не бывает, поэтому нс-3 Устройство CSMA
не моделирует обнаружение столкновений, и никакая текущая передача не будет "заблокирована".

CSMA Слой Модель
Существует ряд соглашений, используемых для описания многоуровневой связи.
архитектуры в литературе и учебниках. Самая распространенная модель наслоения - это
Семислойная эталонная модель ISO. В этом представлении пара CsmaNetDevice и CsmaChannel
занимает два нижних уровня - физический (уровень один) и канал передачи данных (уровень два)
позиции. Другой важной эталонной моделью является модель, указанная в RFC 1122, «Требования
для хостов Интернета - Уровни связи ». В этом представлении CsmaNetDevice и
Пара CsmaChannel занимает самый нижний уровень - канальный уровень. Есть также, казалось бы,
бесконечный перечень альтернативных описаний в учебниках и литературе. Мы
принять соглашения об именах, используемые в стандартах IEEE 802, которые говорят о LLC, MAC, MII
и PHY слоев. Эти сокращения определяются как:

· ООО: Logical Link Control;

· MAC: управление доступом к среде передачи;

· MII: медиа-независимый интерфейс;

· PHY: физический уровень.

В этом случае ООО и MAC являются подуровнями канального уровня OSI и MII и PHY
являются подуровнями физического уровня OSI.

«Верх» устройства CSMA определяет переход от сетевого уровня к данным.
канальный уровень. Этот переход выполняется более высокими уровнями путем вызова либо
CsmaNetDevice :: Send или CsmaNetDevice :: SendFrom.

В отличие от стандартов IEEE 802.3, в CSMA нет точно указанного физического уровня.
модель в смысле типов проводов, сигналов или распиновки. «Нижний» интерфейс
CsmaNetDevice можно рассматривать как своего рода Media Independent Interface (MII), как показано
в спецификациях «Fast Ethernet» (IEEE 802.3u). Этот интерфейс MII вписывается в
соответствующий медиа-независимый интерфейс на CsmaChannel. Вы не найдете
эквивалент 10BASE-T или 1000BASE-LX PHY.

CsmaNetDevice вызывает CsmaChannel через медиа-независимый интерфейс. Eсть
метод, определенный, чтобы сообщить каналу, когда начинать "шевелить проводами" с помощью метода
CsmaChannel :: TransmitStart и метод, чтобы сообщить каналу, когда процесс передачи
готово, и канал должен начать распространение последнего бита по «проводу»:
CsmaChannel :: TransmitEnd.

При выполнении метода TransmitEnd канал будет моделировать единый однородный сигнал.
задержка распространения в среде и доставка копий пакета на каждое из устройств
прикрепляется к пакету с помощью метода CsmaNetDevice :: Receive.

В независимом от носителя интерфейсе устройства есть «контакт», соответствующий «COL».
(столкновение). Состояние канала можно определить, вызвав CsmaChannel :: GetState. Каждый
устройство посмотрит на этот "контакт" перед началом отправки и выполнит соответствующую отсрочку
операции при необходимости.

Правильно полученные пакеты пересылаются на более высокие уровни от CsmaNetDevice через
механизм обратного вызова. Функция обратного вызова инициализируется более высоким уровнем (когда сеть
подключено устройство) с помощью CsmaNetDevice :: SetReceiveCallback и вызывается при "правильном"
прием пакета сетевым устройством для пересылки пакета по протоколу
стек.

CSMA Канал Модель
Класс CsmaChannel моделирует фактическую среду передачи. Нет фиксированного лимита на
количество устройств, подключенных к каналу. CsmaChannel моделирует скорость передачи данных и
задержка скорости света, доступ к которой можно получить через атрибуты DataRate и Delay.
соответственно. Скорость передачи данных, предоставляемая каналу, используется для установки скоростей передачи данных, используемых
секции передатчика устройств CSMA, подключенных к каналу. Нет возможности
самостоятельно устанавливать скорости передачи данных в устройствах. Поскольку скорость передачи данных используется только для расчета
время задержки, нет никаких ограничений (кроме типа данных, содержащего значение) на
скорость, с которой могут работать каналы и устройства CSMA; и никаких ограничений на основании каких-либо
вид PHY характеристик.

CsmaChannel имеет три состояния: IDLE, ПЕРЕДАЧА и РАСПРОСТРАНЕНИЕ. Эти три состояния
мгновенно "видны" всеми устройствами на канале. Под этим мы подразумеваем, что если один
устройство начинает или завершает имитацию передачи, все устройства на канале немедленно
осведомлен об изменении состояния. Нет времени, в течение которого одно устройство может видеть IDLE
канал, в то время как другое устройство, физически находящееся дальше в домене коллизии, может иметь
начал передачу с соответствующими сигналами, которые не распространяются по каналу на другие
устройств. Таким образом, нет необходимости в обнаружении столкновений в модели CsmaChannel, и это
никак не реализовано.

Как видно из названия, у нас есть аспект Carrier Sense для модели. Поскольку
симулятор является однопоточным, доступ к общему каналу будет сериализован
симулятор. Это обеспечивает детерминированный механизм борьбы за канал. В
канал выделен (перешел из состояния IDLE заявить ПЕРЕДАЧА) в порядке очереди
в порядке очереди. Канал всегда проходит через процесс с тремя состояниями:

ПРОХОЖДЕНИЕ -> ПЕРЕДАЧА -> РАСПРОСТРАНЕНИЕ -> ПРОХОЖДЕНИЕ

Команда ПЕРЕДАЧА state моделирует время, в течение которого исходное сетевое устройство фактически
покачивание сигналов на проводе. В РАСПРОСТРАНЕНИЕ состояние моделирует время после последнего бита
был отправлен, когда сигнал распространяется по проводу до «дальнего конца».

Переход к ПЕРЕДАЧА состояние управляется призывом к
CsmaChannel :: TransmitStart, который вызывается сетевым устройством, передающим пакет. Это
это устройство обязано завершить передачу вызовом
CsmaChannel :: TransmitEnd в соответствующее время моделирования, которое отражает прошедшее время
поставить все биты пакета на провод. Когда вызывается TransmitEnd, канал
планирует событие, соответствующее одной задержке скорости света. Эта задержка распространяется на
все сетевые устройства на канале идентичны. Вы можете представить себе симметричную ступицу, в которой
биты пакета передаются в центральное место, а затем обратно по кабелям одинаковой длины в
другие устройства на канале. Тогда единственная задержка "скорости света" соответствует
время, необходимое для: 1) распространения сигнала от одного CsmaNetDevice по его кабелю
к хабу; плюс 2) время, необходимое концентратору для пересылки пакета через порт; плюс
3) время, необходимое для распространения рассматриваемого сигнала до сети назначения.
устройства.

CsmaChannel моделирует широковещательную среду, поэтому пакет доставляется на все устройства.
на канале (включая источник) в конце времени распространения. Это
ответственность передающего устройства за определение того, получает ли оно пакет
трансляция по каналу.

CsmaChannel предоставляет следующие атрибуты:

· DataRate: скорость передачи пакетов на подключенных устройствах;

· Задержка: скорость задержки передачи света для канала.

CSMA Чистыми Устройство Модель
Сетевое устройство CSMA выглядит как устройство Ethernet. CsmaNetDevice
предоставляет следующие атрибуты:

· Адрес: Mac48-адрес устройства;

· SendEnable: разрешить передачу пакетов, если истинно;

· ReceiveEnable: разрешить прием пакетов, если true;

· EncapsulationMode: тип используемой инкапсуляции канального уровня;

· RxErrorModel: модель ошибки приема;

· TxQueue: очередь передачи, используемая устройством;

· InterframeGap: необязательное время ожидания между «кадрами»;

· Rx: источник трассировки полученных пакетов;

· Drop: источник трассировки для отброшенных пакетов.

CsmaNetDevice поддерживает назначение «модели ошибок приема». Это
ErrorModel, который используется для имитации повреждения данных в ссылке.

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

Также с помощью атрибута можно настроить метод инкапсуляции, используемый устройством. Каждый
пакет получает заголовок EthernetHeader, который включает MAC-адреса назначения и источника, и
поле длины / типа. Каждый пакет также получает EthernetTrailer, который включает FCS.
Данные в пакете могут быть инкапсулированы по-разному.

По умолчанию или при установке для атрибута EncapsulationMode значения «Dix» инкапсуляция
согласно стандарту DEC, Intel, Xerox. Иногда это называют кадрированием EthernetII.
и является знакомым MAC-адресом назначения, исходным MAC-адресом, EtherType, данными, форматом CRC.

Если атрибут «EncapsulationMode» установлен на «Llc», инкапсуляция выполняется LLC SNAP. В
в этом случае добавляется заголовок SNAP, содержащий EtherType (IP или ARP).

Другие реализованные режимы инкапсуляции - IP_ARP (установите "EncapsulationMode" на "IpArp")
в котором тип длины заголовка Ethernet получает номер протокола
пакет; или ETHERNET_V1 (установите "EncapsulationMode" на "EthernetV1"), в котором тип длины
заголовка Ethernet получает длину пакета. "Необработанный" режим инкапсуляции
определено, но не реализовано - использование режима RAW приводит к утверждению.

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

CsmaNetDevice реализует алгоритм случайного экспоненциального отката, который выполняется, если
канал определен как занятый (ПЕРЕДАЧА or ПЕРЕДАЧА) когда устройство хочет
начать размножение. Это приводит к случайной задержке до pow (2, retries) - 1
микросекунды до попытки повтора. Максимальное количество попыток по умолчанию - 1000.

. CsmaNetDevice
Сетевые устройства и каналы CSMA обычно создаются и настраиваются с помощью
ассоциируется CsmaHelper объект. Различные нс-3 помощники устройств обычно работают в аналогичных
таким образом, и их использование видно во многих наших примерах программ.

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

NodeContainer csmaNodes;
csmaNodes.Create(nCsmaNodes);

Когда у вас есть узлы, вам нужно создать экземпляр CsmaHelper и установите любые атрибуты, которые вы
может захотеть поменять .:

CsmaHelper csma;
csma.SetChannelAttribute ("DataRate", StringValue ("100 Мбит / с"));
csma.SetChannelAttribute («Задержка», TimeValue (NanoSeconds (6560)));

csma.SetDeviceAttribute ("EncapsulationMode", StringValue ("Dix"));
csma.SetDeviceAttribute ("Размер кадра", UintegerValue (2000));

После установки атрибутов остается только создать устройства и установить их на
необходимые узлы, а также для соединения устройств с помощью канала CSMA. Когда мы
Создавая сетевые устройства, мы добавляем их в контейнер, чтобы вы могли использовать их в будущем.
Все это занимает всего одну строчку кода:

NetDeviceContainer csmaDevices = csma.Install(csmaNodes);

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

Атрибут Mtu указывает максимальную единицу передачи на устройство. Это размер
самого большого блока данных протокола (PDU), который может отправить устройство. Значение этого атрибута по умолчанию
до 1500 байт и соответствует числу в RFC 894, «Стандарт для
Передача дейтаграмм IP по сетям Ethernet ". Число фактически получено из
максимальный размер пакета для сетей 10Base5 (full-spec Ethernet) - 1518 байт. если ты
вычтите накладные расходы на инкапсуляцию DIX для пакетов Ethernet (18 байт), вы получите
максимально возможный размер данных (MTU) 1500 байт. Также можно обнаружить, что MTU для IEEE
Сети 802.3 составляет 1492 байта. Это связано с тем, что инкапсуляция LLC / SNAP добавляет еще восемь
байтов накладных расходов на пакет. В обоих случаях основное сетевое оборудование
ограничен 1518 байтами, но MTU отличается, потому что инкапсуляция отличается.

Если оставить атрибут Mtu на 1500 байтов и изменить атрибут режима инкапсуляции
в Llc, результатом будет сеть, которая инкапсулирует 1500-байтовые PDU с LLC / SNAP
кадрирование с получением пакетов размером 1526 байт. Это было бы незаконно во многих сетях, но
мы позволяем вам это делать. Это приводит к моделированию, которое довольно тонко не отражает
чего вы могли ожидать, поскольку реальное устройство откажется от отправки пакета размером 1526 байт.

Также существуют jumbo-кадры (1500 <MTU <= 9000 байт) и super-jumbo (MTU> 9000).
байтов), которые официально не санкционированы IEEE, но доступны в некоторых
высокоскоростные (гигабитные) сети и сетевые карты. В модели CSMA можно было оставить
режим инкапсуляции установлен на Dix, а Mtu - на 64000 байт, даже если связанный
CsmaChannel DataRate был оставлен на уровне 10 мегабит в секунду (конечно, не Gigabit Ethernet).
По сути, это моделировало бы коммутатор Ethernet, сделанный из испорченного вампирами стиля 1980-х годов.
Сети 10Base5, поддерживающие супер-большие датаграммы, что, конечно, не является чем-то, что
когда-либо было сделано и вряд ли когда-либо будет сделано; однако вам довольно легко
настройки.

Будьте осторожны с предположениями относительно того, что на самом деле моделирует CSMA и как
Конфигурация (Атрибуты) может позволить вам значительно отклониться от реальности.

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

Верхний уровень (MAC) Крючки
С точки зрения трассировки в сетевом устройстве есть несколько интересных моментов.
для вставки трассировочных крючков. Соглашение, унаследованное от других симуляторов, заключается в том, что пакеты
предназначенные для передачи в подключенные сети, проходят через единую «очередь передачи» в
сетевое устройство. Мы предоставляем перехватчики трассировки в этой точке потока пакетов, что соответствует
(абстрактно) только к переходу от сети к уровню канала передачи данных, и называть их
вместе перехватывает MAC устройства.

Когда пакет отправляется на сетевое устройство CSMA для передачи, он всегда проходит через
очередь передачи. Очередь передачи в CsmaNetDevice наследуется от Queue и, следовательно,
наследует три источника трассировки:

· Источник операции Enqueue (см. Queue :: m_traceEnqueue);

· Источник операции Dequeue (см. Queue :: m_traceDequeue);

· Источник операции Drop (см. Queue :: m_traceDrop).

Перехватчики трассировки верхнего уровня (MAC) для CsmaNetDevice на самом деле являются именно этими тремя
источники трассировки в единой очереди передачи устройства.

Событие m_traceEnqueue запускается, когда пакет помещается в очередь передачи. Этот
происходит в то время, когда CsmaNetDevice :: Send или CsmaNetDevice :: SendFrom вызывается
более высокий уровень, чтобы поставить пакет в очередь для передачи.

Событие m_traceDequeue запускается, когда пакет удаляется из очереди передачи.
Исключение из очереди передачи может произойти в трех ситуациях: 1) Если основной
канал простаивает, когда вызывается CsmaNetDevice :: Send или CsmaNetDevice :: SendFrom,
пакет удаляется из очереди на передачу и сразу же передается; 2) Если
нижележащий канал свободен, пакет может быть удален из очереди и немедленно передан в
внутреннее событие TransmitCompleteEvent, которое работает так же, как прерывание завершения передачи
режим обслуживания; или 3) от обработчика случайной экспоненциальной задержки, если тайм-аут
обнаружено.

Случай (3) подразумевает, что пакет удаляется из очереди передачи, если он не может быть
передается по правилам отсрочки. Важно понимать, что это будет
отображаются как пакет из очереди, и легко ошибочно предположить, что пакет был
передается, так как он прошел через очередь передачи. Фактически, пакет на самом деле
сброшено сетевым устройством в этом случае. Причина такого поведения связана с
определение события Queue Drop. Событие m_traceDrop по определению запускается, когда
пакет не может быть поставлен в очередь на передачу, потому что он заполнен. Это событие только срабатывает
если очередь заполнена, и мы не перегружаем это событие, чтобы указать, что CsmaChannel
"полный."

Нижний уровень (физический уровень) Крючки
Подобно крючкам трассировки верхнего уровня, в нижнем
уровни сетевого устройства. Мы называем это перехватчиками PHY. Эти события запускаются с устройства
методы, которые обращаются напрямую к CsmaChannel.

Источник трассировки m_dropTrace вызывается для указания пакета, который был отброшен устройством.
Это происходит в двух случаях: во-первых, если принимающая сторона сетевого устройства не включена.
(см. CsmaNetDevice :: m_receiveEnable и связанный атрибут «ReceiveEnable»).

M_dropTrace также используется, чтобы указать, что пакет был отброшен как поврежденный, если
используется модель ошибок получения (см. CsmaNetDevice :: m_receiveErrorModel и связанный с ним
атрибут "ReceiveErrorModel").

Другой источник трассировки низкого уровня срабатывает при приеме принятого пакета (см.
CsmaNetDevice :: m_rxTrace). Пакет принимается, если он предназначен для трансляции
адрес, групповой адрес или MAC-адрес, назначенный сетевому устройству.

Резюме
Модель ns3 CSMA - это упрощенная модель сети, подобной Ethernet. Он поддерживает
Функция Carrier-Sense и обеспечивает множественный доступ к общей среде. Нет
физическое в том смысле, что состояние среды мгновенно распределяется между всеми
устройств. Это означает, что в этой модели не требуется обнаружение столкновений и
реализовано. На носителе никогда не будет "застревания" пакета. Доступ к
общий канал работает в порядке очереди, как определено симулятором
планировщик. Если канал определен как занятый, глядя на глобальное состояние,
выполняется случайный экспоненциальный откат и предпринимается попытка повторения.

Атрибуты Ns-3 обеспечивают механизм для установки различных параметров в устройстве и
канал, такой как адреса, режимы инкапсуляции и выбор модели ошибок. Крючки трассировки
снабженный обычным образом набором крючков верхнего уровня, соответствующих передаче
очередь и используется при трассировке ASCII; а также набор хуков нижнего уровня, используемых при трассировке pcap.

Хотя ns-3 CsmaChannel и CsmaNetDevice не моделируют какую-либо сеть, которую вы
можно построить или купить, он действительно предоставляет нам некоторые полезные функции. Вам следует,
однако имейте в виду, что это явно не Ethernet или какой-либо вариант IEEE 802.3, а
интересное подмножество.

ДАННЫЕ КОЛЛЕКЦИЯ

В этой главе описывается структура сбора данных NS-3 (DCF), которая обеспечивает
возможность получать данные, сгенерированные моделями в симуляторе, выполнять в режиме онлайн
сокращение и обработка данных, а также для маршалинга необработанных или преобразованных данных в различные выходные данные
форматов.

В настоящее время фреймворк поддерживает автономные запуски ns-3, которые не зависят от внешних
контроль выполнения программы. Объекты, предоставляемые DCF, могут быть подключены к нс-3 прослеживать
источники для обработки данных.

Исходный код классов находится в каталоге src / stats.

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

Дизайн
DCF состоит из трех основных классов:

· Образец это механизм для измерения и управления выводом данных моделирования, который
используется для наблюдения за интересными событиями. Он производит вывод в виде одного или нескольких нс-3
источники трассировки. Объекты зонда подключены к одной или нескольким трассам поглотителями (Так называемый
Коллекторы), которые обрабатывают образцы в режиме онлайн и готовят их к выходу.

· Коллектор потребляет данные, созданные одним или несколькими объектами Probe. Он выполняет
преобразования данных, такие как нормализация, сокращение и вычисление
базовая статистика. Объекты-коллекторы не производят данные, которые напрямую выводятся
нс-3 пробег; вместо этого они выводят данные в нисходящий поток к другому типу объекта, называемому
Агрегатор, который выполняет эту функцию. Обычно коллекторы выводят свои данные в
также форма источников следа, позволяющая последовательно соединять сборщики.

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

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

Любой автономный нс-3 прогон моделирования, использующий DCF, обычно создает как минимум один
экземпляр каждого из трех вышеупомянутых классов.
[изображение] Обзор системы сбора данных.UNINDENT

Общий поток обработки данных изображен на Данные ‎ Рамки обзор.
Слева бегущая нс-3 изображена симуляция. В процессе работы
При моделировании данные предоставляются моделями через источники трассировки или другими способами.
На схеме показано, что зонды могут быть подключены к этим источникам трассировки для получения данных.
асинхронно, или зонды могут опрашивать данные. Затем данные передаются объекту-сборщику.
который преобразует данные. Наконец, можно подключить агрегатор к выходам
коллектор для создания графиков, файлов или баз данных.
[изображение] Агрегирование структуры сбора данных.UNINDENT

Вариант приведенного выше рисунка представлен в Данные ‎ Рамки агрегирование.
Этот второй рисунок иллюстрирует, что объекты DCF могут быть связаны вместе способом
что нижестоящие объекты принимают входные данные от нескольких вышестоящих объектов. Фигура
концептуально показывает, что несколько зондов могут генерировать выходные данные, которые передаются в один
коллекционер; например, коллектор, который выводит соотношение двух счетчиков, будет
обычно получают данные каждого счетчика от отдельных датчиков. Несколько коллекторов также могут
подавать в единый агрегатор, который (как следует из названия) может собирать ряд данных
потоки для включения в единый график, файл или базу данных.

Данные ‎ Помощники
Полная гибкость структуры сбора данных обеспечивается подключением
зондов, коллекторов и агрегаторов. Выполнение всех этих взаимосвязей приводит к
множество операторов конфигурации в пользовательских программах. Для простоты использования некоторые из наиболее распространенных
операции могут быть объединены и инкапсулированы во вспомогательные функции. Кроме того, некоторые
заявления с участием нс-3 Источники трассировки не имеют привязок Python из-за ограничений в
привязки.

Данные ‎ Помощники Обзор
В этом разделе мы даем обзор некоторых вспомогательных классов, которые были созданы для
упростить настройку структуры сбора данных для некоторых распространенных случаев использования. В
помощники позволяют пользователям формировать общие операции с помощью всего нескольких операторов в их C ++ или
Программы на Python. Но такая простота использования обходится значительно дешевле.
гибкость, которую может обеспечить низкоуровневая конфигурация, и необходимость явно кодировать
поддержка новых типов зондов в помощники (для решения проблемы, описанной ниже).

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

На сегодняшний день реализовано два помощника по сбору данных:

· ГнуплотХелпер

· Помощник по файлам

GnuplotHelper
GnuplotHelper - это вспомогательный класс для создания файлов вывода, используемых для создания gnuplots. В
общая цель - предоставить пользователям возможность быстро строить графики из экспортированных данных.
in нс-3 источники трассировки. По умолчанию выполняется минимальное преобразование данных;
цель состоит в том, чтобы сгенерировать графики с минимальным количеством (по умолчанию) конфигурационных операторов, как
возможное.

GnuplotHelper Обзор
GnuplotHelper создаст 3 разных файла в конце моделирования:

· Файл данных gnuplot, разделенный пробелами

· Контрольный файл gnuplot

· Сценарий оболочки для создания gnuplot

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

void ConfigurePlot (const std :: string & outputFileNameWithoutExtension,
const std :: строка и заголовок,
const std :: string & xLegend,
const std :: string & yLegend,
const std :: string & terminalType = ".png");

Второй оператор перехватывает интересующий источник трассировки:

void PlotProbe (const std :: string & typeId,
const std :: строка и путь,
const std :: string & probeTraceSource,
const std :: string & title);

Аргументы следующие:

· TypeId: нс-3 TypeId зонда

· Path: Путь в нс-3 пространство имен конфигурации для одного или нескольких источников трассировки

· ProbeTraceSource: какой вывод датчика (сам источник трассировки) должен быть нанесен на график.

· Title: заголовок, который нужно связать с набором данных (в легенде gnuplot)

Вариант PlotProbe выше - указать пятый необязательный аргумент, который управляет
где на сюжете ставится ключ (легенда).

Полностью рабочий пример (из седьмой.cc) показан ниже:

// Создаем помощник gnuplot.
GnuplotHelper;

// Настраиваем сюжет.
// Настраиваем сюжет. Первый аргумент - это префикс имени файла.
// для сгенерированных выходных файлов. Второй, третий и четвертый
// аргументами являются, соответственно, заголовок графика, метки оси x и оси y
plotHelper.ConfigurePlot ("счетчик байтов седьмого пакета",
«Зависимость количества байтов пакета от времени»,
"Время (секунды)",
"Счетчик байтов пакета",
"png");

// Укажите тип зонда, путь к источнику трассировки (в пространстве имен конфигурации) и
// зондирование источника трассировки вывода ("OutputBytes") для построения графика. Четвертый аргумент
// указывает имя метки ряда данных на графике. Последний
// аргумент форматирует график, указывая, где должен быть размещен ключ.
plotHelper.PlotProbe (тип зонда,
трассировка,
"OutputBytes",
"Счетчик байтов пакета",
GnuplotAggregator :: KEY_BELOW);

В этом примере тип зонда и трассировка следующие (для IPv4):

probeType = "ns3 :: Ipv4PacketProbe";
tracePath = "/ NodeList / * / $ ns3 :: Ipv4L3Protocol / Tx";

ProbeType является ключевым параметром для работы этого помощника. Этот TypeId должен быть зарегистрирован
в системе, и подпись на приемнике трассировки зонда должна соответствовать сигнатуре трассы.
источник, к которому он подключен. Типы зондов предварительно определены для ряда типов данных.
соответствующий нс-3 отслеживаемые значения, а также для некоторых других сигнатур источников трассировки, таких как
источник трассировки 'Tx' ns3 :: Ipv4L3Protocol класса.

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

Основным результатом будет три файла:

седьмой-пакет-байтов-count.dat
седьмой-пакет-байт-count.plt
седьмой-packet-byte-count.sh

На этом этапе пользователи могут либо вручную отредактировать файл .plt для дальнейшей настройки, либо
просто запустите его через gnuplot. Бег sh седьмой-packet-byte-count.sh просто запускает сюжет
через gnuplot, как показано ниже.
[изображение] 2-D Gnuplot Создано с помощью sevenh.cc Example..UNINDENT

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

· Счетчик байтов пакета-0 соответствует / NodeList / 0 / $ ns3 :: Ipv4L3Protocol / Tx

· Счетчик байтов пакета-1 соответствует / NodeList / 1 / $ ns3 :: Ipv4L3Protocol / Tx

GnuplotHelper Настроить график
GnuplotHelper's ConfigurePlot () Функцию можно использовать для настройки графиков.

Имеет следующий прототип:

void ConfigurePlot (const std :: string & outputFileNameWithoutExtension,
const std :: строка и заголовок,
const std :: string & xLegend,
const std :: string & yLegend,
const std :: string & terminalType = ".png");

У него следующие аргументы:

┌────────────────────────────────┬────────────────── ──────────────────┐
│Аргумент │ Описание │
├────────────────────────────────┼────────────────── ──────────────────┤
│outputFileNameWithoutExtension │ Имя файлов, связанных с gnuplot, для │
│ │ писать без расширения. │
├────────────────────────────────┼────────────────── ──────────────────┤
│title │ Строка заголовка графика для использования │
│ │ этот сюжет. │
└────────────────────────────────┴────────────────── ──────────────────┘

│xLegend │ Легенда для оси x
│ │ ось. │
├────────────────────────────────┼────────────────── ──────────────────┤
│yLegend │ Легенда для вертикали y │
│ │ ось. │
├────────────────────────────────┼────────────────── ──────────────────┤
│terminalType │ Строка установки типа клеммы для │
│ │ выход. Терминал по умолчанию │
│ │ тип - «png». │
└────────────────────────────────┴────────────────── ──────────────────┘

GnuplotHelper's ConfigurePlot () функция настраивает параметры, связанные с графиком для этого
помощник gnuplot, чтобы он создавал файл данных gnuplot, разделенный пробелами, с именем
outputFileNameWithoutExtension + ".dat", файл управления gnuplot с именем
outputFileNameWithoutExtension + ".plt" и сценарий оболочки для создания gnuplot с именем
outputFileNameWithoutExtension + ".sh".

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

plotHelper.ConfigurePlot ("счетчик байтов седьмого пакета",
«Зависимость количества байтов пакета от времени»,
"Время (секунды)",
"Счетчик байтов пакета",
"png");

GnuplotHelper PlotProbe
GnuplotHelper's PlotProbe () Функция может использоваться для построения значений, генерируемых датчиками.

Имеет следующий прототип:

void PlotProbe (const std :: string & typeId,
const std :: строка и путь,
const std :: string & probeTraceSource,
const std :: строка и заголовок,
перечисление GnuplotAggregator :: KeyLocation keyLocation = GnuplotAggregator :: KEY_INSIDE);

У него следующие аргументы:

┌─────────────────┬───────────────────────────────── ───┐
│Аргумент │ Описание │
├─────────────────┼───────────────────────────────── ───┤
│typeId │ ID типа для датчика │
│ │, созданный этим помощником. │
├─────────────────┼───────────────────────────────── ───┤
│path │ Конфигурационный путь для доступа к трассировке │
│ │ источник. │
├─────────────────┼───────────────────────────────── ───┤
│probeTraceSource │ Источник трассировки зонда для │
│ │ доступ. │
├─────────────────┼───────────────────────────────── ───┤
│title │ Название, которое будет связано с │
│ │ этот набор данных │
├─────────────────┼───────────────────────────────── ───┤
│keyLocation │ Расположение ключа в │
│ │ сюжет. Местоположение по умолчанию - │
│ │ внутри. │
└─────────────────┴───────────────────────────────── ───┘

GnuplotHelper's PlotProbe () функция отображает набор данных, созданный путем подключения нс-3
источник трассировки с зондом, созданным помощником, а затем построение значений из
probeTraceSource. Набор данных будет иметь указанный заголовок и будет состоять из
'newValue' на каждой отметке времени.

Если путь конфигурации имеет более одного совпадения в системе из-за наличия подстановочного знака, тогда
будет нанесен один набор данных для каждого совпадения. Заголовки наборов данных будут иметь суффикс
совпадающие символы для каждого из подстановочных знаков в пути конфигурации, разделенные пробелами. За
Например, если предлагаемый заголовок набора данных представляет собой строку «байты», и есть два символа подстановки
в пути, тогда заголовки наборов данных, такие как «байты-0 0» или «байты-12 9», будут возможны как
подписи для построенных наборов данных.

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

plotHelper.PlotProbe ("ns3 :: Ipv4PacketProbe",
"/ NodeList / * / $ ns3 :: Ipv4L3Protocol / Tx",
"OutputBytes",
"Счетчик байтов пакета",
GnuplotAggregator :: KEY_BELOW);

Другой Примеры
Гнуплот Помощник Пример
Чуть более простой пример, чем седьмой.cc пример можно найти в
SRC / статистика / примеры / gnuplot-helper-example.cc. Следующий 2-D gnuplot был создан с использованием
пример.
[изображение] 2-D Gnuplot Создано gnuplot-helper-example.cc Пример..UNINDENT

В этом примере есть объект Emitter, который увеличивает свой счетчик в соответствии с
Процесс Пуассона, а затем выдает значение счетчика в качестве источника трассировки.

Ptr emitter = CreateObject ();
Names :: Add ("/ Names / Emitter", эмиттер);

Обратите внимание, что из-за отсутствия подстановочных знаков в пути, используемом ниже, был использован только 1 поток данных.
нарисовано в сюжете. Этот единственный поток данных на графике просто помечен как «Emitter Count»,
без дополнительных суффиксов, как если бы в пути были подстановочные знаки.

// Создаем помощник gnuplot.
GnuplotHelper;

// Настраиваем сюжет.
plotHelper.ConfigurePlot ("пример-помощника-gnuplot",
"Счетчик эмиттеров в зависимости от времени",
"Время (секунды)",
"Счетчик эмиттеров",
"png");

// Построить график значений, сгенерированных зондом. Путь, который мы предоставляем
// помогает устранить неоднозначность источника следа.
plotHelper.PlotProbe ("ns3 :: Uinteger32Probe",
"/ Имена / Эмитент / Счетчик",
"Вывод",
"Счетчик эмиттеров",
GnuplotAggregator :: KEY_INSIDE);

FileHelper
FileHelper - это вспомогательный класс, используемый для помещения значений данных в файл. Общая цель
чтобы предоставить пользователям возможность быстро создавать форматированные текстовые файлы из экспортированных данных
in нс-3 источники трассировки. По умолчанию выполняется минимальное преобразование данных;
цель состоит в том, чтобы сгенерировать файлы с минимальным количеством (по умолчанию) конфигурационных инструкций, как
возможное.

FileHelper Обзор
FileHelper создаст 1 или несколько текстовых файлов в конце моделирования.

FileHelper может создавать 4 различных типа текстовых файлов:

· Отформатированный

· Разделенные пробелами (по умолчанию)

· Разделенные запятой

· Разделение табуляцией

Отформатированные файлы используют строки формата C-стиля и функцию sprintf () для печати их
значения в записываемом файле.

Следующий текстовый файл с 2 столбцами форматированных значений с именем
седьмой-пакет-байт-счет-0.txt был создан с использованием нового кода, который был добавлен в
оригинал нс-3 Код учебного примера. Отображаются только первые 10 строк этого файла.
здесь для краткости.

Время (секунды) = 1.000e + 00 Количество байтов пакетов = 40
Время (секунды) = 1.004e + 00 Количество байтов пакетов = 40
Время (секунды) = 1.004e + 00 Количество байтов пакетов = 576
Время (секунды) = 1.009e + 00 Количество байтов пакетов = 576
Время (секунды) = 1.009e + 00 Количество байтов пакетов = 576
Время (секунды) = 1.015e + 00 Количество байтов пакетов = 512
Время (секунды) = 1.017e + 00 Количество байтов пакетов = 576
Время (секунды) = 1.017e + 00 Количество байтов пакетов = 544
Время (секунды) = 1.025e + 00 Количество байтов пакетов = 576
Время (секунды) = 1.025e + 00 Количество байтов пакетов = 544

...

Следующий другой текстовый файл с 2 столбцами форматированных значений с именем
седьмой-пакет-байт-счет-1.txt также был создан с использованием того же нового кода, который был добавлен в
Оригинальный нс-3 Код учебного примера. Отображаются только первые 10 строк этого файла.
здесь для краткости.

Время (секунды) = 1.002e + 00 Количество байтов пакетов = 40
Время (секунды) = 1.007e + 00 Количество байтов пакетов = 40
Время (секунды) = 1.013e + 00 Количество байтов пакетов = 40
Время (секунды) = 1.020e + 00 Количество байтов пакетов = 40
Время (секунды) = 1.028e + 00 Количество байтов пакетов = 40
Время (секунды) = 1.036e + 00 Количество байтов пакетов = 40
Время (секунды) = 1.045e + 00 Количество байтов пакетов = 40
Время (секунды) = 1.053e + 00 Количество байтов пакетов = 40
Время (секунды) = 1.061e + 00 Количество байтов пакетов = 40
Время (секунды) = 1.069e + 00 Количество байтов пакетов = 40

...

Ниже приведен новый код, который был добавлен для создания двух текстовых файлов. Подробнее о
этот API будет рассмотрен в следующем разделе.

Обратите внимание, что, поскольку для подстановочного знака в пути было 2 совпадения, 2 отдельных текстовых файла
были созданы. Первый текстовый файл с именем «седьмой-пакет-байт-счет-0.txt»,
соответствует совпадению с подстановочными знаками, в котором "*" заменено на "0". Второй текстовый файл,
который называется "седьмой-пакет-байтов-счет-1.txt", соответствует совпадению с подстановочным знаком с
"*" заменен на "1". Также обратите внимание, что вызов функции WriteProbe () даст
сообщение об ошибке, если для пути, содержащего символы подстановки, нет совпадений.

// Создаем файловый помощник.
Помощник по файлуПомощник по файлу;

// Настраиваем файл для записи.
fileHelper.ConfigureFile ("счетчик байтов седьмого пакета",
FileAggregator :: FORMATTED);

// Устанавливаем метки для этого отформатированного выходного файла.
fileHelper.Set2dFormat ("Время (секунды) =% .3e \ tPacket Byte Count =% .0f");

// Записываем значения, сгенерированные зондом.
fileHelper.WriteProbe ("ns3 :: Ipv4PacketProbe",
"/ NodeList / * / $ ns3 :: Ipv4L3Protocol / Tx",
"OutputBytes");

FileHelper Настроить файл
FileHelper's ConfigureFile () Функция может использоваться для настройки текстовых файлов.

Имеет следующий прототип:

void ConfigureFile (const std :: string & outputFileNameWithoutExtension,
перечислить FileAggregator :: FileType fileType = FileAggregator :: SPACE_SEPARATED);

У него следующие аргументы:

┌────────────────────────────────┬────────────────── ──────────────────┐
│Аргумент │ Описание │
├────────────────────────────────┼────────────────── ──────────────────┤
│outputFileNameWithoutExtension │ Имя выходного файла для записи │
│ │ без расширения. │
├────────────────────────────────┼────────────────── ──────────────────┤
│fileType │ Тип файла для записи. │
│ │ тип файла по умолчанию - пробел │
│ │ разделены. │
└────────────────────────────────┴────────────────── ──────────────────┘

FileHelper's ConfigureFile () функция настраивает параметры, связанные с текстовым файлом, для
файловый помощник, чтобы он создавал файл с именем outputFileNameWithoutExtension plus
возможная дополнительная информация из совпадений с подстановочными знаками плюс ".txt" со значениями, напечатанными как
указанный в fileType. Тип файла по умолчанию разделен пробелами.

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

fileHelper.ConfigureFile ("счетчик байтов седьмого пакета",
FileAggregator :: FORMATTED);

FileHelper WriteProbe
FileHelper's WriteProbe () функция может использоваться для записи значений, сгенерированных датчиками, в
текстовые файлы.

Имеет следующий прототип:

void WriteProbe (const std :: string & typeId,
const std :: строка и путь,
const std :: string & probeTraceSource);

У него следующие аргументы:

┌─────────────────┬───────────────────────────────── ───┐
│Аргумент │ Описание │
├─────────────────┼───────────────────────────────── ───┤
│typeId │ Идентификатор типа для зонда │
│ │ создан. │
├─────────────────┼───────────────────────────────── ───┤
│path │ Конфигурационный путь для доступа к трассировке │
│ │ источник. │
├─────────────────┼───────────────────────────────── ───┤
│probeTraceSource │ Источник трассировки зонда для │
│ │ доступ. │
└─────────────────┴───────────────────────────────── ───┘

FileHelper's WriteProbe () функция создает выходные текстовые файлы, сгенерированные путем подключения
источник трассировки ns-3 с зондом, созданным помощником, а затем записывает значения из
probeTraceSource. Имена выходных файлов будут содержать текст, хранящийся в переменной-члене
m_outputFileNameWithoutExtension плюс ".txt", и будет состоять из 'newValue' на каждом
отметка времени.

Если путь конфигурации имеет более одного совпадения в системе из-за наличия подстановочного знака, тогда
будет создан один выходной файл для каждого совпадения. Имена выходных файлов будут содержать
текст в m_outputFileNameWithoutExtension плюс совпадающие символы для каждого из
символы подстановки в пути конфигурации, разделенные тире, плюс ".txt". Например, если значение
в m_outputFileNameWithoutExtension есть строка «количество байтов пакета», и есть два
подстановочные знаки в пути, затем имена выходных файлов, такие как "количество-байтов-пакетов-0-0.txt" или
"packet-byte-count-12-9.txt" можно будет использовать в качестве имен для создаваемых файлов.

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

fileHelper.WriteProbe ("ns3 :: Ipv4PacketProbe",
"/ NodeList / * / $ ns3 :: Ipv4L3Protocol / Tx",
"OutputBytes");

Другой Примеры
Файл Помощник Пример
Чуть более простой пример, чем седьмой.cc пример можно найти в
SRC / статистика / примеры / file-helper-example.cc. В этом примере используется только FileHelper.

Следующий текстовый файл с 2 столбцами форматированных значений с именем файл-помощник-пример.txt
был создан на примере. Здесь показаны только первые 10 строк этого файла для
краткость.

Время (секунды) = 0.203 Счетчик = 1
Время (секунды) = 0.702 Счетчик = 2
Время (секунды) = 1.404 Счетчик = 3
Время (секунды) = 2.368 Счетчик = 4
Время (секунды) = 3.364 Счетчик = 5
Время (секунды) = 3.579 Счетчик = 6
Время (секунды) = 5.873 Счетчик = 7
Время (секунды) = 6.410 Счетчик = 8
Время (секунды) = 6.472 Счетчик = 9
...

В этом примере есть объект Emitter, который увеличивает свой счетчик в соответствии с
Процесс Пуассона, а затем выдает значение счетчика в качестве источника трассировки.

Ptr emitter = CreateObject ();
Names :: Add ("/ Names / Emitter", эмиттер);

Обратите внимание, что из-за отсутствия подстановочных знаков в пути, используемом ниже, был использован только 1 текстовый файл.
созданный. Этот единственный текстовый файл называется просто "file-helper-example.txt", без дополнительных
суффиксы, как если бы в пути были подстановочные знаки.

// Создаем файловый помощник.
Помощник по файлуПомощник по файлу;

// Настраиваем файл для записи.
fileHelper.ConfigureFile ("пример-помощника-файла",
FileAggregator :: FORMATTED);

// Устанавливаем метки для этого отформатированного выходного файла.
fileHelper.Set2dFormat ("Время (секунды) =% .3e \ tCount =% .0f");

// Записываем значения, сгенерированные зондом. Путь, который мы
// provide помогает устранить неоднозначность источника трассировки.
fileHelper.WriteProbe ("ns3 :: Uinteger32Probe",
"/ Имена / Эмитент / Счетчик",
"Вывод");

Объем и ограничения
В настоящее время реализованы только эти зонды, подключенные к GnuplotHelper и
в FileHelper:

· Логический зонд

· Двойной зонд

· Uinteger8Probe

· Uinteger16Probe

· Uinteger32Probe

· ТаймПроб

· ПакетПроб

· ПриложениеПакетПробе

· IPv4PacketProbe

Следовательно, эти зонды - единственные доступные TypeIds, которые можно использовать в PlotProbe () и
WriteProbe ().

В следующих нескольких разделах мы рассмотрим каждый из основных типов объектов (Probe, Collector,
и агрегатор) более подробно и покажите, как их можно связать вместе с помощью
API нижнего уровня.

Зонды
В этом разделе подробно описаны функции, предоставляемые классом Probe для нс-3
моделирование и дает примеры того, как их кодировать в программе. Этот раздел предназначен для
пользователи, заинтересованные в разработке моделирования с нс-3 инструменты и использование данных
Платформа Collection Framework, частью которой является класс Probe, для генерации вывода данных с помощью
результаты их моделирования.

Образец Обзор
Предполагается, что объект Probe связан с переменной из моделирования, значения которой
на протяжении всего эксперимента актуальны для пользователя. Зонд запишет, что было
значения, принимаемые переменной во время моделирования, и передать эти данные другому
член структуры сбора данных. Хотя это выходит за рамки этого раздела,
обсудить, что происходит после того, как зонд выдает выходной сигнал, достаточно сказать, что
в конце моделирования пользователь получит подробную информацию о том, какие значения были
хранится внутри переменной, исследуемой во время моделирования.

Обычно зонд подключается к нс-3 источник трассировки. Таким образом, всякий раз, когда
источник трассировки экспортирует новое значение, зонд потребляет это значение (и экспортирует его ниже по потоку).
к другому объекту через его собственный источник трассировки).

Зонд можно рассматривать как своего рода фильтр по источникам трассировки. Основные причины
возможно подключение к зонду, а не напрямую к источнику трассировки:

· Зонды могут динамически включаться и выключаться во время моделирования с вызовами Давать возможность()
и Запрещать(). Например, вывод данных может быть отключен во время
фаза прогрева симуляции.

· Зонды могут выполнять операции с данными для извлечения значений из более сложных
конструкции; например, вывод значения размера пакета из полученного ns3 :: Packet.

· Зонды регистрируют имя в пространстве имен ns3 :: Config (используя Имена :: Добавить ()) так что другие
объекты могут ссылаться на них.

· Зонды предоставляют статический метод, который позволяет манипулировать Зондом по имени, например
что сделано в ns2measure [Cic06]

Stat :: put ("my_metric", ID, образец);

Эквивалент ns-3 приведенного выше кода ns2measure, например

DoubleProbe :: SetValueByPath ("/ путь / к / зонд", образец);

Создание
Обратите внимание, что объект базового класса Probe не может быть создан, потому что он является абстрактной базой.
class, т.е. в нем есть чисто виртуальные функции, которые не были реализованы. Объект
Тип DoubleProbe, который является подклассом класса Probe, будет создан здесь, чтобы показать
Что должно быть сделано.

Один объявляет DoubleProbe в динамической памяти с помощью класса интеллектуального указателя (Ptr ). К
создать DoubleProbe в динамической памяти с помощью интеллектуальных указателей, просто нужно вызвать
нс-3 метод CreateObject ():

Ptr myprobe = CreateObject ();

Приведенное выше объявление создает DoubleProbes с использованием значений по умолчанию для его атрибутов.
В классе DoubleProbe есть четыре атрибута; два в объекте базового класса
DataCollectionObject и два в базовом классе Probe:

· «Имя» (DataCollectionObject), StringValue

· «Включено» (DataCollectionObject), логическое значение

· «Старт» (зонд), значение времени

· «Стоп» (зонд), значение времени

Такие атрибуты можно установить при создании объекта следующим способом:

Ptr myprobe = CreateObjectWithAttributes (
«Имя», StringValue («myprobe»),
«Включено», BooleanValue (false),
«Старт», TimeValue (Секунды (100.0)),
«Стоп», TimeValue (Секунды (1000.0)));

Start и Stop - это временные переменные, которые определяют интервал действия зонда. В
Зонд будет выводить данные только в том случае, если текущее время моделирования находится внутри этого
интервал. Специальное значение времени 0 секунд для Stop отключит этот атрибут (т. Е.
держите зонд включенным на протяжении всей симуляции). Включено - это флаг, который включает зонд или
выключен, и для зондирования необходимо установить значение true для экспорта данных. Имя - это имя объекта.
в рамках DCF.

Импортирующий и экспорт данным
нс-3 Источники трассировки строго типизированы, поэтому механизмы привязки зондов к трассировке
source и для экспорта данных принадлежат его подклассам. Например, по умолчанию
распределение нс-3 предоставляет класс DoubleProbe, который предназначен для привязки к трассировке
источник, экспортирующий двойное значение. Далее мы подробно рассмотрим работу DoubleProbe и
затем обсудите, как другие классы Probe могут быть определены пользователем.

Двойной зонд Обзор
DoubleProbe подключается к двойному нс-3 источник трассировки, и сам экспортирует
разные двузначные нс-3 источник трассировки.

Следующий код, взятый из SRC / статистика / примеры / double-probe-example.cc, показывает основные
операции по подключению DoubleProbe к моделированию, где он исследует счетчик
экспортируется объектом-эмиттером (класс Emitter).

Ptr emitter = CreateObject ();
Names :: Add ("/ Names / Emitter", эмиттер);
...

Ptr probe1 = CreateObject ();

// Подключаем зонд к счетчику эмиттера
bool connected = probe1-> ConnectByObject («Счетчик», эмиттер);

Следующий код проверяет тот же счетчик, экспортированный тем же объектом-эмиттером. Этот
Однако DoubleProbe использует путь в пространстве имен конфигурации, чтобы
связь. Обратите внимание, что эмиттер зарегистрировался в пространстве имен конфигурации после
это было создано; в противном случае ConnectByPath не будет работать.

Ptr probe2 = CreateObject ();

// Обратите внимание, здесь не проверяется возвращаемое значение
probe2-> ConnectByPath ("/ Имена / Эмиттер / Счетчик");

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

Ptr probe3 = CreateObject ();
probe3-> SetName ("StaticallyAccessedProbe");

// Мы должны добавить его в базу конфигурации
Names :: Add ("/ Names / Probes", проба3-> GetName (), проба3);

Функция эмиттера Count () теперь может устанавливать значение для этого DoubleProbe как
следующим образом:

аннулировать
Emitter :: Count (недействительно)
{
...
m_counter + = 1.0;
DoubleProbe :: SetValueByPath ("/ Имена / StaticallyAccessedProbe", m_counter);
...
}

В приведенном выше примере показано, как код, вызывающий зонд, не должен иметь явного
ссылка на Probe, но может направлять настройку значения через пространство имен Config.
По функциям он похож на Stat :: Put Метод, представленный ns2measure paper
[Cic06] и позволяет пользователям временно вставлять операторы Probe, например Printf отчетность
в рамках существующих нс-3 модели. Обратите внимание, что для использования DoubleProbe в этом
В этом примере потребовалось 2 вещи:

1. файл заголовка модуля статистики был включен в пример файла .cc

2. пример был сделан зависимым от модуля статистики в файле wscript.

Аналогичные действия необходимо сделать, чтобы добавить другие зонды в другие места в папке. нс-3
кодовая база.

Значения для DoubleProbe также можно установить с помощью функции DoubleProbe :: SetValue (),
в то время как значения для DoubleProbe можно получить с помощью функции
DoubleProbe :: GetValue ().

DoubleProbe экспортирует двойные значения в свой источник трассировки «Выход»; нижестоящий объект
может подключить приемник трассировки (NotifyViaProbe) к этому следующим образом:

connected = probe1-> TraceConnect ("Выход", probe1-> GetName (), MakeCallback (& ​​NotifyViaProbe));

Другой Зонды
Помимо DoubleProbe, также доступны следующие датчики:

· Uinteger8Probe подключается к нс-3 источник трассировки, экспортирующий файл uint8_t.

· Uinteger16Probe подключается к нс-3 источник трассировки, экспортирующий файл uint16_t.

· Uinteger32Probe подключается к нс-3 источник трассировки, экспортирующий файл uint32_t.

· PacketProbe подключается к нс-3 источник трассировки, экспортирующий пакет.

· ApplicationPacketProbe подключается к нс-3 источник трассировки, экспортирующий пакет и сокет
адрес.

· Ipv4PacketProbe подключается к нс-3 источник трассировки, экспортирующий пакет, объект IPv4 и
интерфейс.

Создающий новый Образец Типы
Чтобы создать новый тип зонда, вам необходимо выполнить следующие шаги:

· Убедитесь, что ваш новый класс Probe является производным от базового класса Probe.

· Убедитесь, что чистые виртуальные функции, которые ваш новый класс Probe наследует от
Реализован базовый класс зонда.

· Найдите существующий класс Probe, который использует источник трассировки, наиболее близкий по типу к
тип источника трассировки, который будет использовать ваш зонд.

· Скопируйте файл заголовка существующего класса Probe (.h) и файл реализации (.cc) в два
новые файлы с именами, соответствующими вашему новому зонду.

· Замените типы, аргументы и переменные в скопированных файлах соответствующими
тип для вашего зонда.

· Внесите необходимые изменения, чтобы код компилировался и вел себя так, как вы
нравится.

Примеры
Здесь мы подробно рассмотрим два примера:

· Пример двойного зонда

· Пример построения пакета IPv4

двойной Образец Пример
Пример двойного зонда обсуждался ранее. Пример программы можно найти
in SRC / статистика / примеры / double-probe-example.cc. Подводя итог тому, что происходит в этой программе,
есть эмиттер, который экспортирует счетчик, который увеличивается в соответствии с процессом Пуассона.
В частности, показаны два способа выдачи данных:

1. через отслеживаемую переменную, подключенную к одному зонду:

TracedValue m_counter; // обычно это будет целочисленный тип

2. через счетчик, значение которого отправляется второму Зонду, на который ссылается его имя в
Конфигурационная система:

аннулировать
Emitter :: Count (недействительно)
{
NS_LOG_FUNCTION (это);
NS_LOG_DEBUG ("Подсчет в" << Simulator :: Now () .GetSeconds ());
m_counter + = 1.0;
DoubleProbe :: SetValueByPath ("/ Имена / StaticallyAccessedProbe", m_counter);
Simulator :: Schedule (Seconds (m_var-> GetValue ()), & Emitter :: Count, this);
}

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

1. Зонд напрямую обращается к источнику трассировки и подключает к нему приемник трассировки.

2. Зонд получает доступ к источнику трассировки через пространство имен config и подключает
проследить за ним

3. вызывающим кодом, явно вызывающим зонд SetValue () метод

4. вызывающим кодом, явно вызывающим SetValueByPath
("/ путь / через / Config / пространство имен", ...)

Ожидается, что первые два метода будут наиболее распространенными. Также в примере
показано подключение нормальной функции обратного вызова, как это обычно делается в нс-3. Это
функция обратного вызова не связана с объектом Probe. Мы назовем этот случай ниже 0).

// Это функция для проверки подключения необработанной функции к источнику трассировки
аннулировать
NotifyViaTraceSource (std :: string context, double oldVal, double newVal)
{
NS_LOG_DEBUG ("context:" << context << "old" << oldVal << "new" << newVal);
}

Во-первых, необходимо настроить эмиттер:

Ptr emitter = CreateObject ();
Names :: Add ("/ Names / Emitter", эмиттер);

// Объект Emitter не связан с узлом ns-3, поэтому
// он не запустится автоматически, поэтому нам нужно сделать это самим
Simulator :: Schedule (секунды (0.0), & Emitter :: Start, emitter);

Различные DoubleProbes взаимодействуют с эмиттером в примере, как показано ниже.

Случай 0):

// Ниже показаны типичные функции без зонда
// (подключаем функцию-приемник к источнику трассировки)
//
connected = emitter-> TraceConnect («Счетчик», «пример контекста», MakeCallback (& ​​NotifyViaTraceSource));
NS_ASSERT_MSG (подключено, «Источник трассировки не подключен»);

Дело 1):

//
// Probe1 будет подключен непосредственно к объекту источника трассировки Emitter
//

// probe1 будет подключен к источнику трассировки Emitter
Ptr probe1 = CreateObject ();
// имя зонда может служить его контекстом при трассировке
probe1-> SetName ("ObjectProbe");

// Подключаем зонд к счетчику эмиттера
connected = probe1-> ConnectByObject («Счетчик», эмиттер);
NS_ASSERT_MSG (подключено, «Источник трассировки не подключен к датчику 1»);

Дело 2):

//
// Probe2 будет подключен к объекту источника трассировки Emitter с помощью
// доступ к нему по имени пути в базе данных Config
//

// Создаем еще один похожий зонд; это будет подключаться через путь конфигурации
Ptr probe2 = CreateObject ();
probe2-> SetName ("PathProbe");

// Обратите внимание, здесь не проверяется возвращаемое значение
probe2-> ConnectByPath ("/ Имена / Эмиттер / Счетчик");

case 4) (случай 3 в этом примере не показан):

//
// Probe3 будет вызываться эмиттером напрямую через
// статический метод SetValueByPath ().
//
Ptr probe3 = CreateObject ();
probe3-> SetName ("StaticallyAccessedProbe");
// Мы должны добавить его в базу конфигурации
Names :: Add ("/ Names / Probes", проба3-> GetName (), проба3);

И, наконец, пример показывает, как можно подключить зонды для генерации вывода:

// Сам зонд должен генерировать выходные данные. Контекст, который мы предоставляем
// к этому зонду (в данном случае имя зонда) поможет устранить неоднозначность
// источник следа
connected = probe3-> TraceConnect ("Выход",
"/ Имена / Зонды / StaticallyAccessedProbe / Выход",
MakeCallback (& ​​NotifyViaProbe));
NS_ASSERT_MSG (подключен, «Источник трассировки не .. подключен к выходу датчика 3»);

Следующий обратный вызов подключен к Probe в этом примере в иллюстративных целях;
обычно зонд будет привязан к объекту Collector.

// Это функция для тестирования подключения к выходу зонда
аннулировать
NotifyViaProbe (std :: string context, double oldVal, double newVal)
{
NS_LOG_DEBUG ("context:" << context << "old" << oldVal << "new" << newVal);
}

IPv4 пакет Участок Пример
Пример построения пакета IPv4 основан на примере Friday.cc из нс-3 Руководство. Это
можно найти в SRC / статистика / примеры / ipv4-packet-plot-example.cc.

узел 0 узел 1
+ ---------------- + + ---------------- +
| нс-3 TCP | | нс-3 TCP |
+ ---------------- + + ---------------- +
| 10.1.1.1 | | 10.1.1.2 |
+ ---------------- + + ---------------- +
| точка-точка | | точка-точка |
+ ---------------- + + ---------------- +
| |
+ --------------------- +

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

Есть и другие аспекты этого примера, которые будут объяснены позже в документации.
Два типа экспортируемых данных - это сам пакет (Результат) и подсчет
количество байтов в пакете (Выходные байты).

Идентификатор типа
Ipv4PacketProbe :: GetTypeId ()
{
статический TypeId tid = TypeId ("ns3 :: Ipv4PacketProbe")
.SetParent ()
.AddConstructor ()
.AddTraceSource ("Вывод",
«Пакет плюс его объект IPv4 и интерфейс, которые служат выходными данными для этого зонда»,
MakeTraceSourceAccessor (& Ipv4PacketProbe :: m_output))
.AddTraceSource ("Выходные байты",
"Количество байтов в пакете",
MakeTraceSourceAccessor (& Ipv4PacketProbe :: m_outputBytes))
;
вернуть tid;
}

Когда приемник трассировки зонда получает пакет, если зонд включен, он выводит
пакет на его Результат источник трассировки, но он также будет выводить количество байтов в
Выходные байты источник трассировки.

аннулировать
Ipv4PacketProbe :: TraceSink (Ptr пакет, Ptr ipv4, интерфейс uint4_t)
{
NS_LOG_FUNCTION (этот << интерфейс пакета << ipv4 <<);
если (IsEnabled ())
{
m_packet = пакет;
m_ipv4 = ipv4;
m_interface = интерфейс;
m_output (пакет, ipv4, интерфейс);

uint32_t packetSizeNew = packet-> GetSize ();
m_outputBytes (m_packetSizeOld, packageSizeNew);
m_packetSizeOld = packageSizeNew;
}
}

Рекомендации
[Cic06]
Клаудио Чикконетти, Энцо Мингоцци, Джованни Стеа, «Интегрированная платформа для
Обеспечение эффективного сбора данных и статистического анализа с помощью ns2, семинар по
нс-2 (WNS2), Пиза, Италия, октябрь 2006 г.

Коллекторы
Этот раздел является заполнителем для подробного описания функций, предоставляемых Collector.
класс к нс-3 моделирование и дает примеры того, как их кодировать в программе.

Примечание: Начиная с версии ns-3.18, коллекторы все еще находятся в стадии разработки и еще не входят в состав
каркаса.

Накопители
В этом разделе подробно описаны функции, предоставляемые классом Aggregator для нс-3
моделирование. Этот раздел предназначен для пользователей, заинтересованных в разработке моделирования с помощью
нс-3 инструменты и использование Data Collection Framework, класс Aggregator является
часть, чтобы генерировать выходные данные с результатами их моделирования.

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

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

Обратите внимание на следующее об агрегаторах:

· Агрегаторы могут динамически включаться и выключаться во время моделирования с вызовами
Давать возможность() и Запрещать(). Например, агрегирование данных может быть отключено во время
фаза прогрева моделирования, что означает, что эти значения не будут включены в окончательный
средство вывода.

· Агрегаторы получают данные от коллекторов через обратные вызовы. Когда коллектор связан
к агрегатору выполняется вызов TraceConnect для установления трассировки агрегатора.
приемник как обратный вызов.

На сегодняшний день реализовано два агрегатора:

· ГнуплотАгрегатор

· Файловый агрегатор

GnuplotАгрегатор
GnuplotAggregator создает файлы вывода, используемые для создания gnuplots.

В конце моделирования GnuplotAggregator создаст 3 разных файла:

· Файл данных gnuplot, разделенный пробелами

· Контрольный файл gnuplot

· Сценарий оболочки для создания gnuplot

Создание
Здесь будет создан объект типа GnuplotAggregator, чтобы показать, что нужно сделать.

Один объявляет GnuplotAggregator в динамической памяти с помощью класса интеллектуального указателя.
(Птр ). Чтобы создать GnuplotAggregator в динамической памяти с интеллектуальными указателями, достаточно
необходимо позвонить в нс-3 метод CreateObject (). Следующий код из
SRC / статистика / примеры / gnuplot-aggregator-example.cc показывает, как это сделать:

строка fileNameWithoutExtension = "gnuplot-aggregator";

// Создаем агрегатор.
Ptr агрегатор =
CreateObject (имя_файлаWithoutExtension);

Первый аргумент конструктора fileNameWithoutExtension - это имя
Файлы, связанные с gnuplot, для записи без расширения. Этот GnuplotAggregator создаст
разделенный пробелами файл данных gnuplot с именем "gnuplot-aggregator.dat", управляющий файл gnuplot
с именем "gnuplot-aggregator.plt" и сценарий оболочки для создания gnuplot с именем +
"gnuplot-aggregator.sh".

Созданный gnuplot может иметь свой ключ в 4 разных местах:

· Нет ключа

· Ключ внутри сюжета (по умолчанию)

· Ключ над сюжетом

· Ключ под сюжетом

Следующие значения перечисления местоположения ключа gnuplot могут указывать положение ключа:

перечисление KeyLocation {
НЕТ КЛЮЧА,
КЛЮЧ_ВНУТРИ,
KEY_ВЫШЕ,
KEY_BELOW
};

Если было желательно, чтобы ключ был внизу, а не в положении по умолчанию внутри, тогда
вы могли бы сделать следующее.

агрегатор-> SetKeyLocation (GnuplotAggregator :: KEY_BELOW);

Примеры
Здесь будет подробно обсуждаться один пример:

· Пример агрегатора Gnuplot

Гнуплот Агрегатор Пример
Пример использования GnuplotAggregator можно найти в
SRC / статистика / примеры / gnuplot-aggregator-example.cc.

Следующий двухмерный gnuplot был создан с использованием этого примера.
[изображение] 2-D Gnuplot Создано gnuplot-aggregator-example.cc Пример..UNINDENT

Этот код из примера показывает, как создать GnuplotAggregator, как обсуждалось.
выше.

недействительным Create2dPlot ()
{
использование пространства имен std;

строка fileNameWithoutExtension = "gnuplot-aggregator";
string plotTitle = "График агрегатора Gnuplot";
string plotXAxisHeading = "Время (секунды)";
строка plotYAxisHeading = "Двойные значения";
string plotDatasetLabel = "Значения данных";
строка datasetContext = "Набор данных / Контекст / Строка";

// Создаем агрегатор.
Ptr агрегатор =
CreateObject (имя_файлаWithoutExtension);

Устанавливаются различные атрибуты GnuplotAggregator, включая двумерный набор данных, который будет
нанесен.

// Устанавливаем свойства агрегатора.
агрегатор-> SetTerminal ("png");
агрегатор-> SetTitle (plotTitle);
агрегатор-> SetLegend (plotXAxisHeading, plotYAxisHeading);

// Добавляем набор данных в агрегатор.
агрегатор-> Add2dDataset (datasetContext, plotDatasetLabel);

// агрегатор должен быть включен
агрегатор-> Включить ();

Затем вычисляются двумерные значения, и каждое из них индивидуально записывается в
GnuplotAggregator, использующий Write2d () функции.

двойное время;
двойное значение;

// Создаем двумерный набор данных.
для (время = -5.0; время <= +5.0; время + = 1.0)
{
// Расчет двухмерной кривой
//
// 2
// значение = время.
//
значение = время * время;

// Добавляем эту точку на график.
агрегатор-> Write2d (контекст набора данных, время, значение);
}

// Отключаем ведение журнала данных для агрегатора.
агрегатор-> Отключить ();
}

ФайлАгрегатор
FileAggregator отправляет полученные значения в файл.

FileAggregator может создавать файлы 4 различных типов:

· Отформатированный

· Разделенные пробелами (по умолчанию)

· Разделенные запятой

· Разделение табуляцией

Отформатированные файлы используют строки формата C-стиля и функцию sprintf () для печати их
значения в записываемом файле.

Создание
Здесь будет создан объект типа FileAggregator, чтобы показать, что нужно сделать.

Один объявляет FileAggregator в динамической памяти с помощью класса интеллектуального указателя (Ptr ).
Чтобы создать FileAggregator в динамической памяти с интеллектуальными указателями, достаточно вызвать
нс-3 метод CreateObject. Следующий код из
SRC / статистика / примеры / file-aggregator-example.cc показывает, как это сделать:

строка fileName = "файл-агрегатор-форматированные-значения.txt";

// Создаем агрегатор, который будет иметь форматированные значения.
Ptr агрегатор =
CreateObject (имя_файла, FileAggregator :: ОТФОРМАТИРОВАННОЕ);

Первым аргументом конструктора, filename, является имя файла для записи; в
Второй аргумент, fileType, - это тип файла для записи. Этот FileAggregator создаст
файл с именем "file-aggregator-formatted-values.txt" с его значениями, напечатанными, как указано
fileType, т. е. отформатированный в данном случае.

Допускаются следующие значения перечисления типов файлов:

перечисление ТипФайла {
ФОРМАТИРОВАННЫЙ,
SPACE_SEPARATED,
РАЗДЕЛЕННЫЕ ЗАПЯТОЙ,
TAB_SEPARATED
};

Примеры
Здесь будет подробно обсуждаться один пример:

· Пример агрегатора файлов

Файл Агрегатор Пример
Пример использования FileAggregator можно найти в
SRC / статистика / примеры / file-aggregator-example.cc.

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

-5,25
-4,16
-3,9
-2,4
-1,1
0,0
1,1
2,4
3,9
4,16
5,25

Этот код из примера показывает, как создать FileAggregator, как обсуждалось.
выше.

недействительным CreateCommaSeparatedFile ()
{
использование пространства имен std;

строка fileName = "файл-агрегатор-запятыми.txt";
строка datasetContext = "Набор данных / Контекст / Строка";

// Создаем агрегатор.
Ptr агрегатор =
CreateObject (имя_файла, FileAggregator :: COMMA_SEPARATED);

Атрибуты FileAggregator установлены.

// агрегатор должен быть включен
агрегатор-> Включить ();

Затем вычисляются двумерные значения, и каждое из них индивидуально записывается в
FileAggregator, использующий Write2d () функции.

двойное время;
двойное значение;

// Создаем двумерный набор данных.
для (время = -5.0; время <= +5.0; время + = 1.0)
{
// Расчет двухмерной кривой
//
// 2
// значение = время.
//
значение = время * время;

// Добавляем эту точку на график.
агрегатор-> Write2d (контекст набора данных, время, значение);
}

// Отключаем ведение журнала данных для агрегатора.
агрегатор-> Отключить ();
}

Следующий текстовый файл с 2 столбцами форматированных значений также был создан с использованием
пример.

Время = -5.000e + 00 Значение = 25
Время = -4.000e + 00 Значение = 16
Время = -3.000e + 00 Значение = 9
Время = -2.000e + 00 Значение = 4
Время = -1.000e + 00 Значение = 1
Время = 0.000e + 00 Значение = 0
Время = 1.000e + 00 Значение = 1
Время = 2.000e + 00 Значение = 4
Время = 3.000e + 00 Значение = 9
Время = 4.000e + 00 Значение = 16
Время = 5.000e + 00 Значение = 25

Этот код из примера показывает, как создать FileAggregator, как обсуждалось.
выше.

недействительным CreateFormattedFile ()
{
использование пространства имен std;

строка fileName = "файл-агрегатор-форматированные-значения.txt";
строка datasetContext = "Набор данных / Контекст / Строка";

// Создаем агрегатор, который будет иметь форматированные значения.
Ptr агрегатор =
CreateObject (имя_файла, FileAggregator :: ОТФОРМАТИРОВАННОЕ);

Устанавливаются атрибуты FileAggregator, включая используемую строку формата C.

// Устанавливаем формат значений.
агрегатор-> Set2dFormat ("Время =% .3e \ tValue =% .0f");

// агрегатор должен быть включен
агрегатор-> Включить ();

Затем вычисляются двумерные значения, и каждое из них индивидуально записывается в
FileAggregator, использующий Write2d () функции.

двойное время;
двойное значение;

// Создаем двумерный набор данных.
для (время = -5.0; время <= +5.0; время + = 1.0)
{
// Расчет двухмерной кривой
//
// 2
// значение = время.
//
значение = время * время;

// Добавляем эту точку на график.
агрегатор-> Write2d (контекст набора данных, время, значение);
}

// Отключаем ведение журнала данных для агрегатора.
агрегатор-> Отключить ();
}

адаптеры
В этом разделе подробно описаны функции, предоставляемые классом адаптера для нс-3
моделирование. Этот раздел предназначен для пользователей, заинтересованных в разработке моделирования с помощью
нс-3 инструменты и использование Data Collection Framework, частью которого является класс Adapter,
для генерации выходных данных с результатами их моделирования.

Примечание: термин «адаптер» может также записываться как «адаптер»; мы выбрали орфографию с выравниванием
со стандартом C ++.

адаптер Обзор
Адаптер используется для установления соединений между различными типами объектов DCF.

На сегодняшний день реализован один Адаптер:

· Адаптер временных рядов

Время Серии адаптер
TimeSeriesAdaptor позволяет зондам подключаться напрямую к агрегаторам без необходимости
Коллектор посередине.

Оба реализованных помощника DCF используют TimeSeriesAdaptors для проверки
значения разных типов и выводят текущее время плюс значение с обоими преобразованными
в два раза.

Роль класса TimeSeriesAdaptor - роль адаптера, который принимает необработанные значения
проверяет данные разных типов и выводит кортеж из двух двойных значений. Первый - это
метка времени, которая может иметь различное разрешение (например, секунды, миллисекунды и т. д.) в
будущее, но которое в настоящее время жестко запрограммировано на Seconds. Второй - это преобразование
не двойное значение, а двойное значение (возможно, с потерей точности).

Объем / ограничения
В этом разделе обсуждаются объем и ограничения структуры сбора данных.

В настоящее время в DCF реализованы только эти Зонды:

· Логический зонд

· Двойной зонд

· Uinteger8Probe

· Uinteger16Probe

· Uinteger32Probe

· ТаймПроб

· ПакетПроб

· ПриложениеПакетПробе

· IPv4PacketProbe

В настоящее время в DCF нет доступных коллекторов, хотя BasicStatsCollector находится под
развития.

В настоящее время в DCF реализованы только следующие агрегаторы:

· ГнуплотАгрегатор

· Файловый агрегатор

В настоящее время в DCF реализован только этот адаптер:

Адаптер временных рядов.

Будущее Рабочая
В этом разделе обсуждается будущая работа, которую предстоит проделать в рамках структуры сбора данных.

Вот некоторые вещи, которые еще предстоит сделать:

· Подключите больше источников трассировки в нс-3 код, чтобы получить больше значений из симулятора.

· Внедрить больше типов зондов, чем есть в настоящее время.

· Реализуйте больше, чем просто текущий двумерный сборщик, BasicStatsCollector.

· Внедрить больше агрегаторов.

· Реализуйте больше, чем просто адаптеры.

ДСДВ МАРШРУТ

Протокол маршрутизации с вектором расстояния до места назначения (DSDV) является проактивным,
протокол маршрутизации на основе таблиц для MANET, разработанный Charles E. Perkins и Pravin
Bhagwat в 1994 году. Он использует количество переходов в качестве метрики при выборе маршрута.

Эта модель была разработана РесилиНетс исследованиями группы в Канзасском университете. А
статья по этой модели существует в этой URL.

ДСДВ Маршрутизация Обзор
Таблица маршрутизации DSDV: каждый узел будет поддерживать таблицу, в которой перечислены все другие узлы, которые он имеет.
известен либо напрямую, либо через некоторых соседей. Каждый узел имеет одну запись в
таблица маршрутизации. Запись будет содержать информацию о последнем известном IP-адресе узла.
порядковый номер и количество переходов для достижения этого узла. Наряду с этими деталями таблица
также отслеживает следующего соседа, который достигнет узла назначения, отметка времени
последнее обновление, полученное для этого узла.

Сообщение об обновлении DSDV состоит из трех полей: адрес назначения, порядковый номер и
Счетчик хмеля.

Каждый узел использует 2 механизма для отправки обновлений DSDV. Они есть,

1.

Периодический Обновления
Периодические обновления отправляются после каждого m_periodicUpdateInterval (по умолчанию: 15 с).
В этом обновлении узел транслирует всю свою таблицу маршрутизации.

2.

Вызывать Обновления
Обновления триггеров - это небольшие обновления между периодическими обновлениями. Эти обновления
отправляются всякий раз, когда узел получает пакет DSDV, который вызвал изменение в его
таблица маршрутизации. В исходном документе не было четко указано, когда для каких изменений
в таблице на случай отправки обновления DSDV. Текущая реализация отправляет
вне зависимости от изменения в таблице маршрутизации.

Обновления принимаются на основе метрики для конкретного узла. Первый фактор
Определением принятия обновления является порядковый номер. Он должен принять обновление
если порядковый номер сообщения обновления выше независимо от метрики. Если
получено обновление с тем же порядковым номером, затем обновление с наименьшей метрикой (hopCount)
имеет приоритет.

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

Текущая реализация охватывает все перечисленные выше функции DSDV. Электрический ток
реализация также имеет очередь запросов для буферизации пакетов, у которых нет маршрутов к
назначения. По умолчанию установлено буферизацию до 5 пакетов на одно место назначения.

Рекомендации
Ссылка на статью: http://portal.acm.org/citation.cfm? doid = 190314.190336

DSR МАРШРУТ

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

Эта модель была разработана РесилиНетс исследованиями группы в Канзасском университете.

DSR Маршрутизация Обзор
Эта модель реализует базовую спецификацию протокола динамической маршрутизации от источника (DSR).
Реализация основана на RFC 4728, с некоторыми расширениями и модификациями RFC
технические условия.

DSR работает по требованию. Следовательно, наша модель DSR буферизует все пакеты, пока
пакет запроса маршрута (RREQ) распространяется. Мы реализуем буфер пакетов в
dsr-rsendbuff.cc. Очередь пакетов реализует сборку мусора старых пакетов и
ограничение размера очереди. Когда пакет отправляется из буфера отправки, он будет помещен в очередь в
буфер обслуживания для подтверждения следующего перехода.

Затем буфер обслуживания буферизует уже отправленные пакеты и ожидает
уведомление о доставке пакета. Работа протокола сильно зависит от неработающей ссылки
механизм обнаружения. Мы реализуем три эвристики, рекомендованные на основе RFC, как
следующим образом:

Во-первых, мы используем обратную связь на канальном уровне, когда это возможно, что также является самым быстрым механизмом
эти три для обнаружения ошибок связи. Ссылка считается разорванной, если передача кадра
приводит к сбою передачи для всех повторных попыток. Этот механизм предназначен для активных
ссылки и работает намного быстрее, чем при его отсутствии. DSR может обнаруживать канальный уровень
отказ трансмиссии и уведомить об этом как о поломке. Будет запущен пересчет маршрутов
при необходимости. Если пользователь не хочет использовать подтверждение на канальном уровне, его можно настроить с помощью
установка для атрибута LinkAcknowledgment значения false в dsr-routing.cc.

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

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

Реализация Route Cache поддерживает сборку мусора старых записей и состояний.
машина, как определено в стандарте. Он реализуется как контейнер карты STL. Ключ - это
IP-адрес получателя.

DSR работает с прямым доступом к IP-заголовку и работает между сетью и транспортом.
слой. Когда пакет отправляется с транспортного уровня, он передается в DSR и DSR.
заголовок добавлен.

У нас есть два механизма кеширования: кеш пути и кеш ссылок. Кэш пути сохраняет все
путь в кеше. Пути сортируются на основе количества переходов, и всякий раз, когда один путь
не может быть использован, мы переходим на следующий путь. Кеш ссылок немного лучше
дизайн в том смысле, что он использует разные подпути и использует реализованный кэш ссылок, используя
Алгоритм Дийсктры, и эта часть реализована Сонг Луан[электронная почта защищена]>.

Следующие необязательные оптимизации протокола не реализованы:

· Состояние потока

· Флаги First Hop External (F), Last Hop External (L)

· Обработка неизвестных опций DSR

·

Две Типы of ошибка заголовки:

1. состояние потока не поддерживается.

2. неподдерживаемый вариант (не будет в симуляции)

DSR обновление in нс-3.17
Первоначально мы использовали "TxErrHeader" в Ptr для обозначения ошибки передачи
конкретный пакет на канальном уровне, однако, он работал некорректно, так как даже когда
пакет был отброшен, этот заголовок не был записан в файл трассировки. Мы привыкли
другой путь реализации механизма уведомления канального уровня. Мы смотрим в
файл трассировки, найдя событие получения пакета. Если мы найдем одно событие приема для данных
пакет, мы считаем это индикатором успешной доставки данных.

Полезное параметры
+ ------------------------- + ----------------------- ------------- + ------------- +
| Параметр | Описание | По умолчанию |
+ ========================== + ====================== ============== + ============= +
| MaxSendBuffLen | Максимальное количество пакетов, которые могут | 64 |
| | храниться в буфере отправки | |
+ ------------------------- + ----------------------- ------------- + ------------- +
| MaxSendBuffTime | Максимальное время ожидания пакетов в очереди | Секунд(30) |
| | в буфере отправки | |
+ ------------------------- + ----------------------- ------------- + ------------- +
| MaxMaintLen | Максимальное количество пакетов, которые могут | 50 |
| | храниться в буфере обслуживания | |
+ ------------------------- + ----------------------- ------------- + ------------- +
| MaxMaintTime | Максимальное время ожидания пакетов в очереди | Секунд(30) |
| | в буфере обслуживания | |
+ ------------------------- + ----------------------- ------------- + ------------- +
| MaxCacheLen | Максимальное количество записей маршрута | 64 |
| | которые можно сохранить в кеш-памяти маршрутов | |
+ ------------------------- + ----------------------- ------------- + ------------- +
| RouteCacheTimeout | Максимальное время, в течение которого кеш маршрута может | Секунд(300) |
| | быть поставленным в очередь в кеш-память маршрута | |
+ ------------------------- + ----------------------- ------------- + ------------- +
| RreqRetries | Максимальное количество повторных передач | 16 |
| | для запроса открытие маршрута | |
+ ------------------------- + ----------------------- ------------- + ------------- +
| CacheType | Используйте Link Cache или используйте Path Cache | "LinkCache" |
| | | |
+ ------------------------- + ----------------------- ------------- + ------------- +
| LinkAcknowledgment | Включить подтверждение на канальном уровне | Правда |
| | механизм | |
+ ------------------------- + ----------------------- ------------- + ------------- +

Реализация модификация
·

Команда Дсрфсхедер и добавленный 3 поля: сообщение типа, источник идентификатор назначение идентификатор и эти
изменения Важно для Постобработка

1. Тип сообщения используется для идентификации пакета данных из контрольного пакета.

2. Идентификатор источника используется для идентификации реального источника пакета данных, поскольку у нас есть
доставлять пакет поэтапно, а ipv4header не несет реального
исходный и целевой IP-адрес по мере необходимости

3. Идентификатор места назначения используется по той же причине, что и выше

· Заголовок Route Reply не выравнивается по словам в DSR RFC, измените его на выравнивание по словам в
реализация

· DSR работает как шим-заголовок между транспортным и сетевым протоколом, ему нужен собственный
механизм пересылки, мы меняем передачу пакетов на пошаговую доставку, поэтому
мы добавили два поля в фиксированный заголовок DSR для уведомления о доставке пакета

Текущий Маршрут Кэш реализация
В этой реализации использовался "кеш пути", который прост в реализации и обеспечивает отсутствие петель.
пути:

· Кэш пути имеет политику автоматического истечения срока действия

· Кеш сохраняет несколько записей маршрута для определенного пункта назначения и сортирует записи
на основе подсчета хмеля

· MaxEntriesEachDst можно настроить для изменения максимального количества записей, сохраняемых для одного
назначение

· При добавлении нескольких маршрутов для одного пункта назначения, маршрут сравнивается на основе
число переходов и время истечения срока действия, маршрут с меньшим числом переходов или относительно новый маршрут
благоприятствования

· Будущая реализация может включать в себя «кеш ссылок» в качестве другой возможности.

DSR инструкции
При использовании DSR в качестве протокола маршрутизации следует иметь в виду следующее:

· NodeTraversalTime - время, необходимое для обхода двух соседних узлов, и должно быть
выбран, чтобы соответствовать диапазону передачи

· PassiveAckTimeout - время ожидания пакета в буфере обслуживания для пассивного
подтверждение, обычно устанавливается как два времени NodeTraversalTime

· RouteCacheTimeout следует установить меньшее значение, когда скорость узлов становится выше.
Значение по умолчанию - 300 секунд.

Помощник
Чтобы узел запускал DSR, проще всего использовать DsrHelper и DsrMainHelpers.
в вашем сценарии моделирования. Например:

дсрхелпер дср;
дсрмаинхелпер дсрмаин;
dsrMain.Install (dsr, adhocNodes);

Примеры скриптов внутри SRC / DSR / примеры / продемонстрировать использование узлов на основе DSR в
разные сценарии. Источник помощника можно найти внутри
src / dsr / helper / dsr-main-helper. {h, cc} и SRC / DSR / помощник / DSR-помощник. {h, cc}

Примеры
Пример можно найти в SRC / DSR / примеры /:

· Dsr.cc использует DSR как протокол маршрутизации в традиционной среде MANET [3].

DSR также встроен в случай сравнения маршрутизации в примеры / маршрутизация /:

· manet-routing-compare.cc это случай сравнения со встроенными протоколами маршрутизации MANET и
может генерировать свои собственные результаты.

Проверка
Эта модель была протестирована следующим образом:

· Модульные тесты были написаны для проверки внутреннего устройства DSR. Это можно найти в
SRC / DSR / тест / dsr-test-suite.cc. Эти тесты проверяют, используются ли методы внутри модуля DSR
которые имеют дело с буфером пакетов, заголовки работают правильно.

· Примеры моделирования, подобные [3], были протестированы и дали сопоставимые результаты.

· Manet-routing-compare.cc был использован для сравнения DSR с тремя другими маршрутами
протоколы.

Доклад об этих результатах был представлен на семинаре по нс-3 в 2011 году.

ограничения
Модель не полностью соответствует RFC 4728. Например, заголовок фиксированного размера DSR имеет
был расширен и на четыре октета длиннее спецификации RFC. Как следствие,
заголовки DSR не могут быть правильно декодированы Wireshark.

В будущем планируется полное соответствие модели RFC.

Рекомендации
[1] Исходный документ: http://www.monarch.cs.rice.edu/monarch-papers/dsr-chapter00.pdf

[2] RFC 4728. http://www6.ietf.org/rfc/rfc4728.txt

[3] Сравнительная статья Броха: http://www.monarch.cs.rice.edu/monarch-papers/mobicom98.ps

ЭМУЛЯЦИЯ О проекте

нс-3 был разработан для интеграции в тестовые среды и среды виртуальных машин. Мы
обратились к этой потребности, предоставив два типа сетевых устройств. Первый вид устройства
сетевое устройство дескриптора файла (Фднетдевице), который является универсальным типом устройства, которое может
читать и писать из файлового дескриптора. Связывая этот файловый дескриптор с разными
вещи в хост-системе могут быть предоставлены разные возможности. Например,
FdNetDevice может быть связан с базовым пакетным сокетом для обеспечения эмуляции
возможности. Это позволяет нс-3 симуляции для отправки данных в «настоящую» сеть. Секунда
вид, называемый Нажмите NetDevice позволяет "настоящему" хозяину участвовать в нс-3 моделирование как
если бы это был один из моделируемых узлов. An нс-3 моделирование может быть построено с любым
комбинация смоделированных или смоделированных устройств.

Примечание: До ns-3.17 возможность эмуляции обеспечивалась специальным устройством, называвшимся
an эму NetDevice; в эму NetDevice был заменен на Фднетдевице.

Один из вариантов использования, который мы хотим поддержать, - это испытательный стенд. Конкретный пример
Такого рода средой является полигон ORBIT. ORBIT - лабораторный эмулятор / полевое испытание
сеть организована в виде двухмерной сетки из 400 радиоузлов 802.11. Мы интегрируемся с
ORBIT, используя свой процесс "визуализации" для загрузки и запуска нс-3 симуляции на ОРБИТЕ
множество. Мы можем использовать наши Эмуфднетдевице запустить оборудование на испытательном стенде, и мы сможем
накапливать результаты либо с помощью нс-3 функции трассировки и ведения журнала или собственные
Методы сбора данных ORBIT. Видеть http://www.orbit-lab.org/ подробнее об ОРБИТЕ
обкатки.

Подобное моделирование показано на следующем рисунке:
[image] Пример реализации эмуляции испытательного стенда..UNINDENT

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

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

В том, что можно рассматривать как обратную конфигурацию, мы разрешаем "настоящим" машинам
запускать собственные приложения и стеки протоколов для интеграции с нс-3 моделирование.
Это позволяет моделировать большие сети, подключенные к реальной машине, а также
обеспечивает виртуализацию. Подобное моделирование показано на следующем рисунке:
[image] Обзор реализации эмулируемого канала..UNINDENT

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

Также слева и справа на рисунке показаны две виртуальные машины.
На этих виртуальных машинах работают собственные приложения (Linux) и стеки протоколов. ВМ есть
подключен к моделированию сетевым устройством Linux Tap. Обработчик пользовательского режима для
Устройство Tap создается при моделировании и присоединяется к прокси-узлу, который
представляет собой собственную виртуальную машину в моделировании. Эти обработчики позволяют устройствам Tap на
собственные виртуальные машины, чтобы вести себя так, как если бы они были нс-3 сетевые устройства в виртуальной машине моделирования. Это в
в свою очередь, позволяет собственному программному обеспечению и пакетам протоколов на собственных виртуальных машинах полагать, что
они подключены к смоделированному нс-3 канал.

Мы ожидаем, что типичным вариантом использования этой среды будет анализ поведения
собственные приложения и наборы протоколов при наличии больших смоделированных нс-3
сетей.

Файл дескриптор NetDevice
Команда SRC / fd-net-устройство модуль предоставляет Фднетдевице класс, умеющий читать и
записывать трафик с использованием файлового дескриптора, предоставленного пользователем. Этот файловый дескриптор может быть
связанный с устройством TAP, с сырым сокетом, с процессом пользовательского пространства, генерирующим / потребляющим
трафик и т. д. Пользователь имеет полную свободу определять, как генерируется внешний трафик и
нс-3 трафик расходуется.

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

· EmuFdNetDeviceHelper (чтобы связать нс-3 устройство с физическим устройством в хосте
машина)

· TapFdNetDeviceHelper (чтобы связать устройство ns-3 с файловым дескриптором одним касанием
устройство в хост-машине)

· PlanteLabFdNetDeviceHelper (для автоматизации создания устройств отвода в узлах PlanetLab,
позволяет нс-3 моделирования, которые могут отправлять и получать трафик через Интернет, используя
Ресурс PlanetLab.

Модель Описание
Исходный код этого модуля находится в каталоге SRC / fd-net-устройство.

FdNetDevice - это особый тип нс-3 NetDevice, считывающий трафик в файл и из файла
дескриптор. То есть, в отличие от чистых имитационных объектов NetDevice, которые записывают кадры в
из смоделированного канала это FdNetDevice направляет кадры из моделирования в файл
дескриптор. Дескриптор файла может быть связан с устройством Linux TUN / TAP, с сокетом,
или к процессу в пространстве пользователя.

Пользователь этого устройства должен предоставить дескриптор файла. Тип файла
Предоставляемый дескриптор определяет, что моделируется. Например, если файл
дескриптор предоставляет необработанный сокет для карты WiFi на хост-машине, при этом устройство
Смоделировано устройство Wi-Fi.

С концептуальной «вершины» устройства, смотрящей вниз, он выглядит как смоделированный узел
устройство, поддерживающее 48-битный MAC-адрес IEEE, который может быть соединен мостом, поддерживает широковещательную передачу и
использует IPv4 ARP или IPv6 Neighbor Discovery, хотя эти атрибуты можно настроить на
на основе варианта использования.

Дизайн
Реализация FdNetDevice использует объект чтения, расширенный от FdReader
класс в нс-3 SRC / ядро модуль, который управляет отдельным потоком от основного нс-3
поток выполнения, чтобы читать трафик из файлового дескриптора.

При вызове СтартУстройство метод, объект-читатель инициализируется и запускает
чтение ветки. Перед запуском устройства дескриптор файла должен быть предварительно связан с
FdNetDevice с Сетфайлдескриптор призыв.

Создание и настройку файлового дескриптора можно оставить на усмотрение нескольких помощников,
более подробно описано ниже. Когда это будет сделано, вызов Сетфайлдескриптор is
ответственность помощника, и пользователь не должен вызывать их напрямую.

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

Чтобы не перегружать планировщик при слишком высокой скорости входящих данных,
счетчик хранится с количеством кадров, которые в настоящее время запланированы для приема
Устройство. Если этот счетчик достигает значения, заданного RxQueueSize атрибут в
устройство, то новый кадр будет отброшен без уведомления.

Фактический прием нового кадра устройством происходит, когда запланированный ФордварВверх
метод вызывается симулятором. Этот метод действует так, как если бы новый фрейм прибыл из
канал, подключенный к устройству. Затем устройство декапсулирует рамку, удаляя все слои.
2 и пересылает его на верхние уровни сетевого стека узла. В Вперед
удалит заголовки кадра в соответствии с типом инкапсуляции кадра, определенным
Режим инкапсуляции атрибут и вызвать обратный вызов приема, передав IP-пакет.

Дополнительный заголовок, заголовок PI, может присутствовать, когда дескриптор файла связан с
Устройство TAP, созданное без установки флага IFF_NO_PI. Этот дополнительный заголовок
удалено, если Режим инкапсуляции установлено значение DIXPI.

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

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

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

По умолчанию в качестве MTU устройства используется значение MTU Ethernet II. Однако помощники предполагаются
чтобы установить mtu на правильное значение, чтобы отразить характеристики сетевого интерфейса
связанный с файловым дескриптором. Если помощник не используется, то ответственность
установка правильного значения mtu для устройства возвращается пользователю. Размер прочитанного
буфер на считывателе файлового дескриптора установлен на значение mtu в СтартУстройство метод.

Класс FdNetDevice в настоящее время поддерживает три режима инкапсуляции, DIX для Ethernet II.
кадров, LLC для кадров 802.2 LLC / SNAP и DIXPI для кадров Ethernet II с дополнительным
Заголовок TAP PI. Это означает, что ожидается, что трафик, проходящий через файловый дескриптор, будет
Совместимость с Ethernet II. Присоединение FdNetDevice к беспроводному интерфейсу возможно как
пока драйвер предоставляет фреймы Ethernet II API сокета. Обратите внимание, чтобы связать
FdNetDevice к беспроводной карте в режиме ad-hoc, должен быть установлен MAC-адрес устройства
на настоящий MAC-адрес карты, иначе любой входящий трафик будет поддельным MAC-адресом.
отброшен водителем.

Как упоминалось ранее, с модулем fd-net-device предоставляются три помощника. Каждый
индивидуальный помощник (тип файлового дескриптора) может иметь ограничения платформы. Например,
многопоточность, режим моделирования в реальном времени и возможность создавать устройства TUN / TAP.
предпосылки к использованию предоставленных помощников. Поддержку этих режимов можно найти в
выход WAF конфигурировать шаг, например:

Примитивы потоковой передачи: включены
Симулятор в реальном времени: включен
Эмулированное сетевое устройство: включено
Tap Bridge: включен

Важно отметить, что при тестировании Фднетдевице мы нашли верхнюю границу
ограничение на пропускную способность TCP при использовании каналов Ethernet 1 Гбит / с со скоростью 60 Мбит / с. Этот предел самый
вероятно, из-за вычислительной мощности компьютеров, участвовавших в тестах.

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

FdNetDeviceHelper ФД;
устройства NetDeviceContainer = fd.Install (узлы);

// генерация файлового дескриптора
...

устройство-> SetFileDescriptor (fd);

Чаще всего для взаимодействия с хост-системой будет использоваться FdNetDevice. В этих случаях
почти наверняка пользователь захочет работать в режиме эмуляции в реальном времени и
включить вычисление контрольной суммы. Типичные программные операторы следующие:

GlobalValue :: Bind ("SimulatorImplementationType", StringValue ("ns3 :: RealtimeSimulatorImpl"));
GlobalValue :: Bind ("ChecksumEnabled", BooleanValue (true));

Самый простой способ настроить эксперимент, который взаимодействует с хост-системой Linux, - это пользователь
эму и Нажмите помощники. Пожалуй, самая необычная часть этих вспомогательных реализаций
относится к требованию выполнения некоторого кода с разрешениями суперпользователя.
Вместо того, чтобы заставлять пользователя выполнять всю симуляцию от имени пользователя root, мы предоставляем небольшой
Программа-создатель, которая запускается от имени пользователя root и выполняет любые требуемые сокеты с высоким разрешением.
Самый простой способ установить правильные привилегии для программ-создателей - это включить
--enable-судо флаг при исполнении WAF конфигурировать.

Мы делаем то же самое для обоих эму и Нажмите устройств. Взгляд высокого уровня таков:
CreateFileDescriptor создает локальный межпроцессный (Unix) сокет, вилки и
выполняет небольшую программу создания. Небольшая программа, которая запускается как suid root, создает
сырого сокета и отправляет обратно дескриптор файла сырого сокета через сокет Unix, который
передается ему как параметр. Необработанный сокет передается как управляющее сообщение (иногда
называемые вспомогательными данными) типа SCM_RIGHTS.

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

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

+ ---------------------- + + ----------------------- +
| хост 1 | | хост 2 |
+ ---------------------- + + ----------------------- +
| моделирование нс-3 | | |
+ ---------------------- + | Linux |
| узел нс-3 | | Сетевой стек |
| + ---------------- + | | + ---------------- + |
| | нс-3 TCP | | | | TCP | |
| + ---------------- + | | + ---------------- + |
| | нс-3 ИП | | | | IP | |
| + ---------------- + | | + ---------------- + |
| | Фднетдевице | | | | | |
| | 10.1.1.1 | | | | | |
| + ---------------- + | | + ETHERNET + |
| | сырая розетка | | | | | |
| - + ---------------- + - | | + ---------------- + |
| | эт0 | | | | эт0 | |
+ ------- + ------ + ------- + + -------- + ------ + ------- +

10.1.1.11 10.1.1.12

| |
+ ---------------------------- +

Этот помощник заменяет функциональность ЭмуНетУстройство найти в нс-3 до ns-3.17,
путем включения этого типа устройства в общую структуру FdNetDevice. В
ЭмуНетУстройство устарел в пользу этого нового помощника.

Устройство настроено на выполнение подмены MAC-адресов для разделения сетевого трафика моделирования.
от другого сетевого трафика, который может проходить к узлу и от него.

Этот помощник можно использовать в тестовой ситуации, когда хост, на котором выполняется симуляция,
running имеет определенный интересующий интерфейс, который управляет оборудованием испытательного стенда. Ты бы
также необходимо установить этот конкретный интерфейс в неразборчивый режим и предоставить соответствующий
имя устройства в нс-3 моделирование. Кроме того, аппаратная разгрузка сегментации и
контрольные суммы должны быть отключены.

Помощник работает только в том случае, если базовый интерфейс включен и находится в беспорядочном режиме. Пакеты
будут отправлены через устройство, но мы используем подделку MAC-адресов. MAC-адреса будут
генерируется (по умолчанию) с использованием Организационно-уникального идентификатора (OUI) 00:00:00 в качестве
база. Этот код поставщика не назначен какой-либо организации и поэтому не должен противоречить
любое реальное железо.

Пользователь всегда должен определить, можно ли использовать эти MAC-адреса на вашем компьютере.
сети и не будет конфликтовать ни с чем другим (включая другое моделирование, использующее такие
устройств) в вашей сети. Если вы используете эмулированную конфигурацию FdNetDevice в
отдельное моделирование, вы должны рассмотреть проблемы глобального назначения MAC-адресов и убедиться, что
что MAC-адреса уникальны во всех симуляциях. Эмулируемое сетевое устройство соблюдает
MAC-адрес, указанный в Адрес атрибут, чтобы вы могли сделать это вручную. Для большего
моделирования, вы можете установить OUI в функции распределения MAC-адресов.

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

эмулятор EmuFdNetDeviceHelper;
emu.SetDeviceName (имя устройства);
Устройства NetDeviceContainer = emu.Install (узел);
Ptr device = devices.Get (0);
устройство-> SetAttribute ("Адрес", Mac48AddressValue (Mac48Address :: Allocate ()));

TapFdNetDeviceHelper
Устройство Tap - это особый тип устройства Linux, для которого один конец устройства кажется
ядро как виртуальное net_device, а другой конец предоставляется как файловый дескриптор для
пользовательское пространство. Этот файловый дескриптор можно передать в FdNetDevice. Пакеты отправлены на
устройство TAP ядра будет отображаться в FdNetDevice в нс-3.

Пользователи должны иметь в виду, что это использование устройств TAP отличается от того, что предусмотрено
TapBridge NetDevice обнаружен в SRC / ответвительный мост. Модель в этом помощнике выглядит следующим образом:

+ ------------------------------------- +
| хост |
+ ------------------------------------- +
| моделирование нс-3 | |
+ ---------------------- + |
| узел нс-3 | |
| + ---------------- + | |
| | нс-3 TCP | | |
| + ---------------- + | |
| | нс-3 ИП | | |
| + ---------------- + | |
| | Фднетдевице | | |
| - + ---------------- + - + + ------ + |
| | ТАП | | эт0 | |
| + ------ + + ------ + |
| 192.168.0.1 | |
+ ------------------------------- | ----- +
|
|
------------ (Интернет) -----

В приведенном выше примере конфигурация требует, чтобы хост мог пересылать трафик.
генерируется моделированием в Интернет.

Модель в TapBridge (в другом модуле) выглядит следующим образом:

+ -------- +
| Линукс |
| хост | + ---------- +
| ------ | | призрак |
| приложения | | узел |
| ------ | | -------- |
| стек | | IP | + ---------- +
| ------ | | стек | | узел |
| TAP | | ========== | | -------- |
| устройство | <----- IPC ------> | кран | | IP |
+ -------- + | мост | | стек |
| -------- | | -------- |
| нс-3 | | нс-3 |
| чистая | | чистая |
| устройство | | устройство |
+ ---------- + + ---------- +
|| ||
+ --------------------------- +
| канал нс-3 |
+ --------------------------- +

В приведенном выше примере пакеты проходят через нс-3 NetDevices и каналы.

Шаблон использования для этого примера состоит в том, что пользователь устанавливает MAC-адрес и либо (или
оба) адреса и маски IPv4 и IPv6 на устройстве, а также заголовок PI, если необходимо.
Например:

помощник TapFdNetDeviceHelper;
helper.SetDeviceName (имя устройства);
помощник.SetModePi (режимPi);
helper.SetTapIpv4Address(tapIp);
helper.SetTapIpv4Mask (тапМаска);
...
helper.Install (узел);

PlanetLabFdNetDeviceHelper
PlanetLab - это испытательный стенд всемирной распределенной сети, состоящий из узлов, подключенных к
Интернет. Запуск моделирования ns-3 в узлах PlanetLab с использованием
PlanetLabFdNetDeviceHelper позволяет отправлять моделируемый трафик, генерируемый нс-3, напрямую на
Интернет. Эта настройка может быть полезна для проверки интернет-протоколов NS-3 или других будущих
протоколы, реализованные в ns-3.

Для проведения экспериментов с использованием узлов PlanetLab требуется учетная запись PlanetLab. Только
члены партнерских организаций PlanetLab могут получить такие учетные записи (для получения дополнительной информации
http://www.planet-lab.org/ or http://www.planet-lab.eu ). Как только аккаунт
получено, PlanetLab кусочек должен быть запрошен для проведения экспериментов. Ломтик
представляет собой экспериментальную единицу, относящуюся к группе пользователей PlanetLab, и может быть связан
на виртуальные машины в разных узлах PlanetLab. Срезы также можно настроить, добавив
конфигурационные теги к нему (этим занимаются администраторы PlanetLab).

PlanetLabFdNetDeviceHelper создает устройства TAP на узлах PlanetLab, используя определенные
PlanetLab (например, система vsys) и связывает устройство TAP с
FdNetDevice в нс-3. Функциональность, предоставляемая этим помощником, аналогична той
предоставляется FdTapNetDeviceHelper, за исключением того, что базовые механизмы для создания
Устройства TAP бывают разные.

+ ------------------------------------- +
| Хост PlanetLab |
+ ------------------------------------- +
| моделирование нс-3 | |
+ ---------------------- + |
| узел нс-3 | |
| + ---------------- + | |
| | нс-3 TCP | | |
| + ---------------- + | |
| | нс-3 ИП | | |
| + ---------------- + | |
| | Фднетдевице | | |
| - + ---------------- + - + + ------ + |
| | ТАП | | эт0 | |
| + ------ + + ------ + |
| 192.168.0.1 | |
+ ------------------------------- | ----- +
|
|
------------ (Интернет) -----

Чтобы иметь возможность назначать частные IPv4-адреса устройствам TAP, владельцы учетных записей
должен запросить vsys_vnet теги, которые администраторы PlanetLab добавят в их срез.
Тег vsys_vnet связан с сегментом частной сети и только адреса из этого
отрезок можно использовать в экспериментах.

Синтаксис, используемый для создания устройства TAP с этим помощником, аналогичен синтаксису, используемому для
ранее описанные помощники:

хелпер PlanetLabFdNetDeviceHelper;
helper.SetTapIpAddress(tapIp);
helper.SetTapMask (тапмаск);
...
helper.Install (узел);

Узлы PlanetLab имеют дистрибутив на основе Fedora, поэтому ns-3 можно установить после
инструкция по установке ns-3 Linux.

Атрибуты
Команда Фднетдевице предоставляет ряд атрибутов:

· Адрес: MAC-адрес устройства.

· Начните: Время начала симуляции для раскрутки потока устройства.

· Stop: Время начала симуляции для остановки потока устройства.

· Режим инкапсуляции: Формат инкапсуляции канального уровня

·

RxQueueSize: Команда буфер размер of читать очередь on файл дескриптор
поток (по умолчанию 1000 пакетов)

Начните и Stop обычно не требуется указывать, если пользователь не хочет ограничивать
время, в течение которого это устройство активно. Адрес должен быть установлен на какой-то уникальный
MAC-адрес, если симуляция будет взаимодействовать с другими реальными устройствами каким-либо образом, используя
реальные MAC-адреса. Типичный код:

устройство-> SetAttribute ("Адрес", Mac48AddressValue (Mac48Address :: Allocate ()));

Результат
Трассировка Ascii и PCAP предоставляется аналогично другим нс-3 NetDevice через
помощники, такие как (например):

:: эмулятор EmuFdNetDeviceHelper; Устройства NetDeviceContainer = emu.Install (узел);
emu.EnablePcap ("emu-ping", устройство, истина);

Предоставляется стандартный набор источников трассировки NetDevice на уровне Mac.

· МаксТкс: Источник трассировки срабатывает, когда нс-3 предоставляет устройству новую рамку для отправки

· МаксTxDrop: Источник трассировки при сбое записи в файловый дескриптор

· МаксПромискRx: При получении любого допустимого кадра Mac

· МаксRx: Всякий раз, когда для этого устройства получен действительный фрейм Mac

· Sniffer: Анализатор пакетов без неразборчивых связей

· ПромискСниффер: Сниффер беспорядочных пакетов (для трассировок, подобных tcpdump)

Примеры
Приведено несколько примеров:

· манекен-network.cc: Этот простой пример создает два узла и соединяет их с
Канал Unix путем передачи файловых дескрипторов из пары сокетов в FdNetDevice
объекты соответствующих узлов.

· в реальном времени-пустышка-network.cc: То же, что dummy-network.cc, но использует симулятор реального времени.
реализация вместо стандартной.

· fd2fd-onoff.cc: Этот пример предназначен для измерения пропускной способности FdNetDevice в
чистая симуляция. Для этого два FdNetDevices, подключенных к разным узлам, но в
такая же симуляция, подключаются с помощью пары разъемов. TCP-трафик отправляется в
насыщающая скорость передачи данных.

· fd-emu-onoff.cc: Этот пример предназначен для измерения пропускной способности FdNetDevice.
при использовании EmuFdNetDeviceHelper для присоединения смоделированного устройства к реальному устройству в
хост-машина. Это достигается за счет насыщения канала TCP-трафиком.

· fd-emu-ping.cc: В этом примере EmuFdNetDeviceHelper используется для отправки трафика ICMP через
реальный канал.

· fd-emu-udp-echo.cc: В этом примере EmuFdNetDeviceHelper используется для отправки UDP-трафика через
настоящий канал.

· fd-planetlab-ping.cc: В этом примере показано, как настроить эксперимент для отправки ICMP
трафик с узла PlanetLab в Интернет.

· fd-tap-ping.cc: В этом примере TapFdNetDeviceHelper используется для отправки ICMP-трафика через
реальный канал.

Нажмите NetDevice
Tap NetDevice может использоваться, чтобы позволить хост-системе или виртуальным машинам взаимодействовать с
симуляция.

TapBridge Модель Обзор
Tap Bridge предназначен для интеграции "реальных" интернет-хостов (или, точнее, хостов
которые поддерживают устройства Tun / Tap) в симуляции ns-3. Цель состоит в том, чтобы представить его
"настоящий" хост-узел в том смысле, что он имеет сетевое устройство ns-3 в качестве локального устройства. Концепция
«реальный хост» немного скользкий, поскольку «реальный хост» может быть виртуализирован с помощью
легкодоступные технологии, такие как VMware, VirtualBox или OpenVZ.

Поскольку мы, по сути, подключаем входы и выходы сетевого устройства ns-3 к
входы и выходы сетевого устройства Linux Tap, мы называем это устройство Tap Bridge.

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

Мы называем эти три режима режимами ConfigureLocal, UseLocal и UseBridge. Первое
"слово" в идентификаторе режима верблюжьего регистра указывает, кто несет ответственность за создание
и настройка кранов. Например, «Настроить» в режиме ConfigureLocal указывает
что именно TapBridge отвечает за настройку крана. Используется
режим и режимы UseBridge, префикс «Использовать» указывает, что TapBridge предлагается «Использовать»
существующая конфигурация.

Другими словами, в режиме ConfigureLocal TapBridge отвечает за создание
и настройка устройств TAP. В режимах UseBridge или UseLocal пользователь предоставляет
конфигурации, и TapBridge адаптируется к этой конфигурации.

TapBridge Конфигурлокал режим
В режиме ConfigureLocal конфигурация устройства отвода - ns-3.
конфигурационно-ориентированный. Информация о конфигурации берется с устройства в нс-3.
имитация и устройство ответвления, соответствующее атрибутам ns-3, создается автоматически. В
в этом случае компьютер Linux выглядит так, как если бы он был напрямую подключен к
смоделированная сеть нс-3.

Это проиллюстрировано ниже:

+ -------- +
| Линукс |
| хост | + ---------- +
| ------ | | призрак |
| приложения | | узел |
| ------ | | -------- |
| стек | | IP | + ---------- +
| ------ | | стек | | узел |
| TAP | | ========== | | -------- |
| устройство | <----- IPC ------> | кран | | IP |
+ -------- + | мост | | стек |
| -------- | | -------- |
| нс-3 | | нс-3 |
| чистая | | чистая |
| устройство | | устройство |
+ ---------- + + ---------- +
|| ||
+ --------------------------- +
| канал нс-3 |
+ --------------------------- +

В этом случае «сетевое устройство ns-3» в «призрачном узле» выглядит так, как если бы оно было на самом деле
замена устройства TAP в хосте Linux. Моделирование ns-3 создает устройство TAP на
базовой ОС Linux и настраивает IP- и MAC-адреса устройства TAP в соответствии с
значения, присвоенные моделируемому устройству ns-3 net. Ссылка "IPC", показанная выше, является
механизм подключения к сети в базовой ОС. Вся аранжировка действует как обычная
мост; но мост между устройствами, которые имеют один и тот же общий MAC и IP
адреса.

Здесь от пользователя не требуется предоставлять какую-либо информацию о конфигурации, относящуюся к
кран. Устройство ответвления будет создано и настроено с помощью ns-3 в соответствии с его настройками по умолчанию, и
устройству с ответвлением будет присвоено имя базовой операционной системой в соответствии с
его значения по умолчанию.

Если у пользователя есть требование доступа к созданному устройству с ответвлением, он или она может при желании
укажите атрибут «DeviceName». В этом случае созданное устройство для подключения ОС будет называться
соответственно.

Режим ConfigureLocal является рабочим режимом Tap Bridge по умолчанию.

TapBridge Использоватьлокальный режим
Режим UseLocal очень похож на режим ConfigureLocal. Существенная разница
является, как следует из названия режима, TapBridge собирается «использовать» существующее устройство для разветвления.
ранее созданные и настроенные пользователем. Этот режим особенно полезен, когда
Схема виртуализации автоматически создает устройства с ответвлениями, а ns-3 используется для обеспечения
смоделированные сети для этих устройств.

+ -------- +
| Линукс |
| хост | + ---------- +
| ------ | | призрак |
| приложения | | узел |
| ------ | | -------- |
| стек | | IP | + ---------- +
| ------ | | стек | | узел |
| TAP | | ========== | | -------- |
| устройство | <----- IPC ------> | кран | | IP |
| MAC X | | мост | | стек |
+ -------- + | -------- | | -------- |
| нс-3 | | нс-3 |
| чистая | | чистая |
| устройство | | устройство |
| МАК Y | | МАК Z |
+ ---------- + + ---------- +
|| ||
+ --------------------------- +
| канал нс-3 |
+ --------------------------- +

В этом случае предварительно настроенный MAC-адрес «Tap device» (MAC X) не будет
То же, что и у мостового "сетевого устройства ns-3" (MAC Y), показанного на иллюстрации выше. В
для подключения к сетевым устройствам ns-3, которые не поддерживают SendFrom () (особенно беспроводные
Узлы STA) мы налагаем требование, чтобы только одно устройство Linux (с одним уникальным MAC-адресом
- здесь X) генерирует трафик, который проходит через канал IPC. Это потому, что MAC
адреса трафика по ссылке IPC будут «подделаны» или изменены, чтобы они отображались
Linux и ns-3, что у них одинаковый адрес. То есть трафик, идущий из Linux
хост к узлу-призраку ns-3 изменит свой MAC-адрес с X на Y, а трафик с
MAC-адрес узла-призрака на хост Linux будет изменен с Y на X. Поскольку
между устройствами существует взаимно однозначное соответствие, может быть только один источник MAC
течет со стороны Linux. Это означает, что Linux соединяется с более чем одним сетевым устройством.
добавленные несовместимы с режимом UseLocal.

В режиме UseLocal пользователь должен полностью создать и настроить устройство с ответвлением.
вне рамок моделирования ns-3, используя что-то вроде:

$ sudo tunctl -t Tap0
$ sudo ifconfig tap0 hw ether 08: 00: 2e: 00: 00: 01
$ sudo ifconfig tap0 10.1.1.1 сетевая маска 255.255.255.0 вверх

Чтобы сообщить TapBridge о том, что происходит, пользователь установит либо прямо в
TapBridge или через TapBridgeHelper, атрибут «DeviceName». В случае
конфигурации выше, атрибут "DeviceName" будет установлен на "tap0" и "Mode"
для атрибута будет установлено значение «UseLocal».

Одним из конкретных вариантов использования этого режима является среда OpenVZ. Там возможно
для создания устройства Tap на «Аппаратном узле» и перемещения его на виртуальный частный сервер.
Если TapBridge может использовать существующее устройство разветвления, тогда можно избежать
накладные расходы на мост ОС в этой среде.

TapBridge UseBridge режим
Самый простой режим для тех, кто знаком с сетями Linux, - это режим UseBridge. Снова,
префикс «Использовать» указывает, что TapBridge будет использовать существующую конфигурацию.
В этом случае TapBridge логически расширит мост Linux до ns-3.

Это проиллюстрировано ниже:

+ --------- +
| Linux | + ---------- +
| ------- | | призрак |
| приложения | | узел |
| ------- | | -------- |
| стек | | IP | + ---------- +
| ------- | + -------- + | стек | | узел |
| Виртуальный | | TAP | | ========== | | -------- |
| Устройство | | Устройство | <---- IPC -----> | кран | | IP |
+ --------- + + -------- + | мост | | стек |
|| || | -------- | | -------- |
+ -------------------- + | нс-3 | | нс-3 |
| ОС (brctl) Мост | | чистая | | чистая |
+ -------------------- + | устройство | | устройство |
+ ---------- + + ---------- +
|| ||
+ --------------------------- +
| канал нс-3 |
+ --------------------------- +

В этом случае компьютер, на котором запущены приложения, протоколы Linux и т. Д., Подключается к
ns-3 смоделировал сеть таким образом, чтобы хосту Linux казалось, что TAP
device - это реальное сетевое устройство, участвующее в мосте Linux.

В моделировании ns-3 создается TapBridge для соответствия каждому устройству TAP. Имя
Устройство TAP назначается мосту Tap Bridge с помощью атрибута DeviceName. TapBridge
затем логически расширяет мост ОС, чтобы охватить сетевое устройство ns-3.

Поскольку этот режим логически расширяет мост ОС, на нем может быть много сетевых устройств Linux.
нон-нс-3 сторона моста. Поэтому, как и сетевое устройство на любом мосту, сеть ns-3
устройство должно иметь дело с возможно многими адресами источника. Таким образом, устройства нс-3 должны
поддержка SendFrom () (NetDevice :: SupportsSendFrom () должен возвращать true), чтобы быть
настроен для использования в режиме UseBridge.

Ожидается, что пользователь сделает что-то вроде следующего, чтобы настроить мост.
и нажмите полностью за пределами ns-3:

$ sudo brctl addbr мой мост
$ sudo tunctl -t mytap
$ sudo ifconfig mytap hw ether 00: 00: 00: 00: 00: 01
$ sudo ifconfig mytap 0.0.0.0 вверх
$ sudo brctl addif mybridge mytap
$ sudo brctl addif mybridge...
$ sudo ifconfig mybridge 10.1.1.1 сетевая маска 255.255.255.0 вверх

Чтобы сообщить TapBridge о том, что происходит, пользователь установит либо прямо в
TapBridge или через TapBridgeHelper, атрибут «DeviceName». В случае
конфигурации выше, атрибут "DeviceName" будет установлен на "mytap" и "Mode"
для атрибута будет установлено значение «UseBridge».

Этот режим особенно полезен в случае виртуализации, когда конфигурация
виртуальные хосты могут быть продиктованы другой системой и не могут быть изменены в соответствии с ns-3.
Например, конкретная схема виртуальной машины может создавать виртуальные устройства vethx или vmnetx, которые
кажутся локальными для виртуальных хостов. Чтобы подключиться к таким системам, необходимо:
вручную создайте устройства TAP в хост-системе и подключите эти устройства TAP к
существующие (ВМ) виртуальные устройства. Задача Tap Bridge в этом случае - продлить
мост для подключения к сетевому устройству ns-3.

TapBridge Конфигурлокал Эксплуатация
В режиме ConfigureLocal отображается TapBridge и, следовательно, связанное с ним сетевое устройство ns-3.
к главному компьютеру Linux как к сетевому устройству точно так же, как любой произвольный "eth0" или "ath0"
может появиться. Создание и настройка TAP-устройства выполняется с помощью ns-3.
имитация и ручная настройка не требуется. IP-адреса, MAC
адреса, шлюзы и т. д. для созданных устройств TAP извлекаются из моделирования
сам, запрашивая конфигурацию устройства ns-3 и атрибуты TapBridge.

Поскольку MAC-адреса идентичны на стороне Linux и стороне ns-3, мы можем использовать
Send () на устройстве ns-3, который доступен на всех сетевых устройствах ns-3. Поскольку MAC
адреса идентичны, нет необходимости подключать беспорядочный обратный вызов к
получить сторону. Поэтому нет никаких ограничений на типы сетевых устройств, которые
можно использовать в режиме ConfigureLocal.

TapBridge представляется при моделировании ns-3 бесканальным сетевым устройством. Это устройство
не должен иметь связанный с ним IP-адрес, но мостовое (ns-3) сетевое устройство должно
иметь IP-адрес. Имейте в виду, что это обратное устройство BridgeNetDevice ns-3 (или
обычный мост в целом), который требует, чтобы его порты моста не имели IP-адресов,
но позволяет самому устройству моста иметь IP-адрес.

Главный компьютер будет отображаться при моделировании как «призрачный» узел, содержащий один
TapBridge для каждого NetDevice, к которому выполняется соединение. С точки зрения моделирования,
единственная разница между призрачным узлом и любым другим узлом будет заключаться в наличии
Устройства TapBridge. Однако обратите внимание, что наличие TapBridge действительно влияет на
возможность подключения сетевого устройства к IP-стеку узла-призрака.

Конфигурация адресной информации и устройств NS-3 никоим образом не изменяется, если
TapBridge присутствует. TapBridge получит адресную информацию от NS-3.
сетевое устройство, к которому он подключен (его "мостовое" сетевое устройство), и использовать эту информацию для
создать и настроить устройство TAP на реальном хосте.

Конечным результатом этого является ситуация, когда можно, например, использовать стандартный ping
утилита на реальном хосте для проверки связи смоделированного узла ns-3. Если правильные маршруты добавлены в
Интернет-хост (ожидается, что в будущих версиях ns-3 это будет выполняться автоматически),
системы маршрутизации в ns-3 обеспечат правильную маршрутизацию пакетов через симулированный ns-3
сети. В качестве примера см. Пример программы tap-wifi-dumbbell.cc в
Распределение нс-3.

Tap Bridge живет в каком-то сером мире где-то между хостом Linux и ns-3.
мостовое устройство. С точки зрения Linux этот код выглядит как обработчик пользовательского режима для
сетевое устройство TAP. В режиме ConfigureLocal это устройство Tap автоматически создается
нс-3 моделирование. Когда хост Linux пишет в один из автоматически созданных
/ dev / tap устройства, запись перенаправляется в TapBridge, который живет в мире ns-3;
и с этой точки зрения запись пакета в Linux становится пакетом, прочитанным в Tap
Мост. Другими словами, процесс Linux записывает пакет на устройство с ответвлением, и этот пакет
перенаправляется механизмом подключения к сети в процесс ns-3, где он принимается
TapBridge в результате операции чтения есть. Затем TapBridge записывает пакет в
сетевое устройство ns-3, к которому он подключен; и поэтому кажется, что хост Linux
отправил пакет напрямую через сетевое устройство ns-3 в сеть ns-3.

В обратном направлении пакет, полученный сетевым устройством ns-3, подключенным к Tap
Мост отправляется через обратный вызов приема в TapBridge. Затем TapBridge принимает это
пакет и записывает его обратно на хост, используя механизм подключения к сети. Это напишите в
устройство будет отображаться для хоста Linux, как если бы пакет прибыл на сетевое устройство; и
поэтому, как если бы пакет, полученный сетевым устройством ns-3 во время моделирования, появился
на реальном сетевом устройстве Linux.

Результатом является то, что Tap Bridge, по-видимому, соединяет устройство с ответвлением на хосте Linux в
"реальный мир" для сетевого устройства ns-3 в моделировании. Поскольку устройство TAP и
Мостовое сетевое устройство ns-3 имеет один и тот же MAC-адрес, а IPC-соединение с разветвителем сети не
внешне, этот конкретный тип моста создает впечатление, что сетевое устройство ns-3
фактически установлен на хосте Linux.

Чтобы реализовать это на стороне ns-3, нам понадобится «призрачный узел» в моделировании, чтобы
удерживайте подключенное сетевое устройство ns-3 и TapBridge. Этот узел на самом деле не должен делать
что-нибудь еще в симуляции, так как его задача - просто заставить сетевое устройство появиться в
Linux. Это не просто произвольная политика, это потому, что:

· Биты, отправленные в TapBridge с более высоких уровней в призрачном узле (с помощью TapBridge
Send method) полностью игнорируются. TapBridge сам по себе не подключен к какому-либо
сеть ни в линуксе, ни в нс-3. Вы не можете ни отправлять, ни получать данные через
TapBridge из призрачного узла.

· Мостовое сетевое устройство ns-3 имеет обратный вызов приема, отключенный от узла ns-3 и
повторно подключился к Tap Bridge. Все данные, полученные устройством с мостовым подключением, будут отправлены.
к хосту Linux и не будут получены узлом. С точки зрения
Узел-призрак, вы можете отправить через это устройство, но никогда не сможете получить.

Конечно, если вы понимаете все проблемы, вы можете взять свою судьбу в свои руки.
и делайте все, что хотите - мы активно не мешаем вам использовать призрачный узел для
все, что вы решите. Вы сможете выполнять типичные операции ns-3 с призраком.
узел, если хотите. Интернет-стек, например, должен быть там и функционировать на
этот узел, чтобы участвовать в назначении IP-адресов и глобальной маршрутизации. Тем не мение,
как упоминалось выше, интерфейсы взаимодействуют с любым TapBridge или связанными с ним устройствами мостовой сети.
не будет работать полностью. Если вы точно понимаете, что делаете, вы можете настроить
другие интерфейсы и устройства на призрачном узле и их использование; или воспользуйтесь
рабочая сторона отправки мостовых устройств для создания генераторов трафика. Мы вообще
рекомендую рассматривать этот узел как призрак хоста Linux и оставить его самому себе,
хотя.

TapBridge Использоватьлокальный режим Эксплуатация
Как описано выше, TapBridge действует как мост из «реального» мира в
смоделированный мир нс-3. В случае режима ConfigureLocal жизнь проста, поскольку IP-адрес
адрес устройства Tap совпадает с IP-адресом устройства ns-3 и MAC-адресом
устройство Tap совпадает с MAC-адресом устройства ns-3; и есть индивидуальный
отношения между устройствами.

Вещи немного усложняются, когда устройство Tap внешне настроено с
MAC-адрес отличается от MAC-адреса сетевого устройства ns-3. Обычный способ справиться с этим
Разница в том, что в мостовом устройстве используется беспорядочный режим для приема пакетов.
предназначенные для другого MAC-адреса, и перенаправить их в Linux. Чтобы переехать
пакетов наоборот, обычным решением является SendFrom (), которое позволяет вызывающему абоненту
«подделать» или изменить исходный MAC-адрес, чтобы он соответствовал другому MAC-адресу Linux.

У нас есть особое требование, чтобы иметь возможность подключать виртуальные машины Linux к
беспроводные узлы STA. К сожалению, спецификация 802.11 не дает хорошего способа
реализовать SendFrom (), поэтому мы должны решить эту проблему.

Для этого мы предусмотрели режим UseLocal для Tap Bridge. Этот режим позволяет вам
подходите к проблеме так, как если бы вы создавали мост с одним сетевым устройством. Один
разрешенный адрес на стороне Linux запоминается в TapBridge, и все приходящие пакеты
со стороны Linux повторяются на стороне ns-3 с использованием источника MAC устройства ns-3
адрес. Все пакеты, поступающие со стороны ns-3, повторяются со стороны Linux, используя
запомненный MAC-адрес. Это позволяет нам использовать Send () на стороне устройства ns-3, которое
доступно на всех сетевых устройствах ns-3.

Режим UseLocal идентичен режиму ConfigureLocal, за исключением создания и
конфигурация устройства перехвата и подмена MAC-адреса.

TapBridge UseBridge Эксплуатация
Как описано в разделе режима ConfigureLocal, когда хост Linux пишет в один из
/ dev / tap устройства, запись перенаправляется в TapBridge, который живет в мире ns-3.
В случае использования режима UseBridge эти пакеты необходимо будет отправить на ns-3.
сети, как если бы они были отправлены на устройство, участвующее в мосте Linux. Это означает
вызов метода SendFrom () на мостовом устройстве и предоставление исходного MAC-адреса
нашел в пакете.

В другом направлении пакет, полученный сетевым устройством ns-3, подключается через обратный вызов к
TapBridge. Это должно быть сделано в беспорядочном режиме, так как цель состоит в том, чтобы преодолеть нс-3
net устройство на мост ОС (brctl), частью которого является устройство TAP.

По этим причинам только сетевые устройства ns-3, поддерживающие SendFrom () и имеющие подключаемый
беспорядочные обратные вызовы приема разрешены для участия в режиме UseBridge TapBridge
конфигурации.

Нажмите Мост Канал Модель
Модель канала, связанная с Tap Bridge, отсутствует. Фактически, намерение состоит в том, чтобы сделать
похоже, что настоящий интернет-хост подключен к каналу мостовой сети
устройства.

Нажмите Мост трассировка Модель
В отличие от большинства устройств ns-3, TapBridge не предоставляет никаких стандартных источников трассировки. Этот
потому что мост является посредником, который, по сути, находится на расстоянии одного вызова функции от
мостовое устройство. Мы ожидаем, что перехватчики трассировки в мостовом устройстве будут
достаточно для большинства пользователей,

. TapBridge
Мы ожидаем, что большинство пользователей будут взаимодействовать с устройством TapBridge через
TapBridgeHelper. Пользователи других вспомогательных классов, таких как CSMA или Wifi, должны быть
комфортно с используемыми там идиомами.

ENERGY ФРЕЙМВОРК

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

Модель Описание
Исходный код Energy Framework в настоящее время находится по адресу: SRC / энергия.

Дизайн
Энергетическая структура ns-3 состоит из 3 частей: источника энергии, модели энергии устройства и
Энергетический комбайн. Фреймворк реализован в SRC / энергия / модели папку.

Энергия Источник
Источник энергии представляет собой источник питания на каждом узле. Узел может иметь один или несколько
источники энергии, и каждый источник энергии может быть подключен к нескольким моделям энергии устройства.
Подключение источника энергии к энергетической модели устройства подразумевает, что соответствующее устройство
черпает энергию из источника. Основная функциональность источника энергии заключается в обеспечении
энергия для устройств на узле. Когда энергия полностью истощена из Источника Энергии,
он уведомляет устройства на узле, чтобы каждое устройство могло отреагировать на это событие. Дальше,
каждый узел может получить доступ к объектам источника энергии для получения такой информации, как оставшаяся энергия или
доля энергии (уровень заряда батареи). Это позволяет реализовать протоколы с учетом энергии.
в нс-3.

Чтобы смоделировать широкий спектр источников питания, таких как батареи, источник энергии должен
уметь фиксировать характеристики этих расходных материалов. Есть 2 важных
характеристики или эффекты, связанные с практичными батареями:

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

Восстановление эффект
Увеличение срока службы батареи, когда батарея попеременно разряжается и
состояния простоя.

Чтобы учесть влияние скорости пропускной способности, источник энергии использует ток, потребляемый от
все устройства на одном узле для расчета энергопотребления. Более того, несколько
Сборщики энергии могут быть подключены к источнику энергии для пополнения его энергии.
Источник энергии периодически опрашивает все устройства и сборщики энергии на одном и том же
узел для расчета общего потребляемого тока и, следовательно, потребления энергии. Когда устройство
изменяет состояние, соответствующая Энергетическая Модель Устройства уведомит Источник Энергии об этом
изменится и будет рассчитан новый общий текущий розыгрыш. Точно так же каждый комбайн Energy Harvester
update запускает обновление подключенного источника энергии.

Базовый класс Energy Source хранит список устройств (объекты модели энергии устройства) и
сборщики энергии (объекты сборщика энергии), которые используют конкретный источник энергии
как источник питания. Когда энергия полностью истощится, Источник энергии уведомит всех
устройства в этом списке. Затем каждое устройство может обрабатывать это событие независимо, в зависимости от
желаемое поведение, которого следует придерживаться в случае отключения электроэнергии.

Устройство Энергия Модель
Модель энергии устройства - это модель потребления энергии устройством, установленным на узле.
Он разработан как модель, основанная на состоянии, где предполагается, что каждое устройство имеет несколько
состояний, и каждое состояние связано со значением потребляемой мощности. Всякий раз, когда состояние
устройство изменится, соответствующая модель энергии устройства уведомит Источник энергии о
новый текущий розыгрыш устройства. Затем источник энергии рассчитает новую сумму
текущий розыгрыш и обновить оставшуюся энергию.

Модель энергии устройства также может использоваться для устройств, у которых нет конечного числа
состояния. Например, в электромобиле ток, потребляемый двигателем, определяется
своей скоростью. Поскольку скорость автомобиля может принимать постоянные значения в определенном диапазоне,
невозможно определить набор дискретных состояний работы. Однако, преобразовав
значение скорости в ток напрямую, тот же набор API-интерфейсов модели энергопотребления устройства все еще может
использоваться.

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

Wi-Fi Радио Энергия Модель
Модель WiFi Radio Energy - это модель энергопотребления сетевого устройства Wi-Fi. Это
предоставляет состояние для каждого из доступных состояний уровня PHY: Idle, CcaBusy, Tx, Rx,
ChannelSwitch, сон. Каждое из таких состояний связано со значением (в амперах)
текущий розыгрыш (см. ниже названия соответствующих атрибутов). Модель энергии радиообмена Wi-Fi
PHY Listener зарегистрирован на Wifi PHY, чтобы получать уведомления о каждом состоянии Wifi PHY
переход. При каждом переходе вычисляется энергия, израсходованная в предыдущем состоянии, и
источник энергии уведомляется, чтобы обновить оставшуюся энергию.

Текущая модель Wifi Tx дает возможность вычислить текущее потребление в
состояние передачи как функция номинальной мощности tx (в дБм), что наблюдается в нескольких
экспериментальные измерения. С этой целью прослушиватель PHY модели радиоэнергетики Wi-Fi является
уведомляется о номинальной мощности tx, используемой для передачи текущего кадра, и передает такой
значение для текущей модели Wifi Tx, которая заботится об обновлении текущего отрисовки в Tx
государство. Следовательно, потребление энергии рассчитывается правильно, даже если удаленная станция Wi-Fi
Менеджер выполняет покадровое управление мощностью. В настоящее время текущая модель Linear Wifi Tx
реализован, который вычисляет ток tx как линейную функцию (в соответствии с параметрами
которая может быть указана пользователем) номинальной мощности передачи в дБм.

Модель Wi-Fi Radio Energy предлагает возможность указать вызываемый обратный вызов.
когда источник энергии исчерпан. Если такой обратный вызов не указан, когда Wi-Fi
Radio Energy Model Helper используется для установки модели на устройство, обратный вызов
неявно сделано так, чтобы Wi-Fi PHY был переведен в режим SLEEP (следовательно, никакой кадр не
передается или принимается впоследствии), когда источник энергии истощается. Точно так же это
можно указать обратный вызов, который вызывается, когда источник энергии перезаряжается (что
может произойти, если к источнику энергии подключен сборщик энергии). Если такой
обратный вызов не указан, когда для установки модуля Wifi Radio Energy Helper используется
модели на устройстве неявно выполняется обратный вызов, чтобы Wi-Fi PHY возобновлялся с
Режим SLEEP, когда источник энергии перезаряжается.

Будущее Рабочая
Для моделей энергопотребления устройств мы планируем включить поддержку других моделей уровня PHY.
предоставляемых в ns-3, таких как WiMAX, и для моделирования энергопотребления других не
коммуникационные устройства, такие как универсальный датчик и ЦП. Для источников энергии мы
планируется включить новые типы источников энергии, такие как суперконденсатор и никель-металл
Гидридный (Ni-MH) аккумулятор. Для сборщиков энергии мы планируем внедрить
комбайн, который перезаряжает источники энергии в соответствии с уровнями мощности, определенными в
настраиваемый пользователем набор данных реальных измерений.

Рекомендации
[1] Энергетическая модель ns-2:
http://www.cubinlab.ee.unimelb.edu.au/~jrid/Docs/Manuel-NS2/node204.html

[2] Х. Ву, С. Набар и Р. Поовендран. Энергетическая структура для Network Simulator 3
(нс-3).

[3] М. Хэнди и Д. Тиммерманн. Моделирование мобильных беспроводных сетей с точными
моделирование нелинейных эффектов батареи. В проц. прикладного моделирования и моделирования
(АСМ), 2003.

[4] Д.Н. Рахматов и С.Б. Врудхула. Аналитическая модель батареи высокого уровня для использования в
управление энергопотреблением портативных электронных систем. В проц. IEEE/ACM International
Конференция по автоматизированному проектированию (ICCAD'01), страницы 488–493, ноябрь 2001 г.

[5] Д.Н. Рахматов, С.Б. Врудхула, Д.А. Уоллах. Прогноз срока службы батареи для
энергосберегающие вычисления. В проц. Международного симпозиума по малой мощности 2002 г.
Электроника и дизайн (ISLPED'02), страницы 154–159, 2002 г.

[6] К. Таппарелло, Х. Аятоллахи и В. Хайнцельман. Расширение энергетической основы для
Сетевой симулятор 3 (ns-3). Семинар по ns-3 (WNS3), постерная сессия, Атланта, Джорджия,
США. май 2014 г.

Применение
Основной способ взаимодействия пользователей ns-3 с Energy Framework — через
вспомогательный API и через общедоступные атрибуты фреймворка. Помощник
API определен в источник/энергия/помощник/*.h.

Чтобы использовать структуру энергии, пользователь должен установить источник энергии для узла.
представляющую интерес, соответствующую модель энергопотребления устройств для сетевых устройств и, если
необходимо, один или несколько сборщиков энергии. Источник энергии (объекты) объединены в
каждый узел помощником источника энергии. Чтобы разрешить несколько источников энергии на узел,
мы агрегируем контейнер источника энергии, а не напрямую агрегируем исходный объект.

Объект Energy Source хранит список объектов Energy Model и Energy Harvester.
использование источника в качестве источника питания. Объекты Энергетической модели устройства устанавливаются на
Источник энергии с помощью помощника по модели энергопотребления устройства, в то время как объект Energy Harvester
устанавливается Помощником по сбору энергии. Пользователь может получить доступ к объектам модели энергопотребления устройства.
через объект «Источник энергии» для получения информации об энергопотреблении отдельных
устройства. Кроме того, пользователь может получить доступ к объектам Energy Harvester для сбора
информация о текущей собираемой мощности и общей энергии, собираемой
комбайн.

Примеры
Каталоги примеров, источник/примеры/энергия и примеры/энергия, содержат базовый код
который показывает, как настроить фреймворк.

Помощники
Энергия Источник Помощник
Базовый вспомогательный класс для объектов Energy Source, этот вспомогательный объект Aggregates Energy Source
на узел. Дочерняя реализация этого класса создает фактический объект Energy Source.

Устройство Энергия Модель Помощник
Базовый вспомогательный класс для объектов Device Energy Model, этот вспомогательный класс присоединяет Device Energy
Смоделируйте объекты на объектах источника энергии. Дочерняя реализация этого класса создает
фактический объект модели энергии устройства.

Энергия Сбор урожая Помощник
Базовый вспомогательный класс для объектов Energy Harvester, этот помощник прикрепляет Energy Harvester
объекты на объекты источника энергии. Дочерняя реализация этого класса создает фактический
Объект «Сборщик энергии».

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

Базовый Энергия Источник
· BasicEnergySourceInitialEnergyJ: Начальная энергия, хранящаяся в базовом источнике энергии.

· Базовая энергияПоставкаНапряжениеВ: Начальное напряжение питания для основного источника энергии.

· ПериодическийEnergyUpdateInterval: Время между двумя последовательными периодическими обновлениями энергии.

RV Аккумулятор Модель
· RvBatteryModelPeriodicEnergyUpdateInterval: Интервал выборки модели батареи RV.

· RvBatteryModelOpenCircuitVoltage: Напряжение холостого хода модели батареи RV.

· RvBatteryModelCutoffVoltage: Напряжение отключения модели батареи RV.

· Рвбаттеримоделальфавалуе: Альфа-значение модели батареи RV.

· Рвбаттеримоделбетавалуе: Бета-значение модели батареи RV.

· RvBatteryModelNumOfTerms: количество членов бесконечной суммы для оценки батареи
уровень.

Wi-Fi Радио Энергия Модель
· IdleCurrentA: Ток покоя радиостанции по умолчанию в Амперах.

· CcaBusyCurrentA: Текущее состояние занятости радиостанции CCA по умолчанию в амперах.

· TxCurrentA: Ток радиопередачи в амперах.

· RxCurrentA: Ток радио Rx в Амперах.

· ПереключениеТокА: ток переключателя каналов по умолчанию в амперах.

· SleepCurrentA: Радио Спит ток в Амперах.

· Ткскуррентмодель: Указатель на подключенную текущую модель tx.

Базовый Энергия Комбайн
· ПериодическийHarvestedPowerUpdateInterval: Время между двумя последовательными периодическими обновлениями
собранная мощность.

· УрожайнаяМощность: Случайные переменные, представляющие количество предоставляемой мощности.
с помощью сборщика энергии.

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

Базовый Энергия Источник
· Оставшаяся энергия: оставшаяся энергия в BasicEnergySource.

RV Аккумулятор Модель
· RvBatteryModelBatteryLevel: Уровень заряда батареи модели RV.

· RvBatteryModelBatteryСрок службы: срок службы батареи модели RV.

Wi-Fi Радио Энергия Модель
· Общее потребление энергии: Общее энергопотребление радиоустройства.

Базовый Энергия Комбайн
· Собранная мощность: Текущая мощность, обеспечиваемая BasicEnergyHarvester.

· Всего собрано энергии: Общее количество энергии, собранной BasicEnergyHarvester.

Проверка
Сравнение Energy Framework с реальными устройствами не проводилось. Текущий
реализация Energy Framework проверяется численно на наличие ошибок вычислений. То
Модель батареи RV проверяется путем сравнения результатов с тем, что было представлено в оригинале.
Бумага модели батареи RV.

ПОТОК MONITOR

Модель Описание
Исходный код нового модуля находится в каталоге источник/поток-монитор.

Цель модуля Flow Monitor — предоставить гибкую систему для измерения производительности
сетевые протоколы. Модуль использует датчики, установленные в сетевых узлах, для отслеживания
пакеты, которыми обмениваются узлы, и измеряет ряд параметров. Пакеты
разделены в соответствии с потоком, к которому они принадлежат, где каждый поток определяется в соответствии с
характеристики зонда (например, для IP поток определяется как пакеты с одинаковыми
{протокол, источник (IP, порт), пункт назначения (IP, порт)} кортеж.

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

Дизайн
Модуль Flow Monitor разработан по модульному принципу. Его можно расширить путем подкласса
ns3:: FlowProbe и ns3:: FlowClassifier.

Полный дизайн модуля описан в [FlowMonitor].

Объем и ограничения
На данный момент пробники и классификаторы доступны для IPv4 и IPv6.

Каждый зонд будет классифицировать пакеты по четырем точкам:

· При отправке пакета (трассировки SendOutgoing IPv[4,6])

· При пересылке пакета (трассировки UnicastForward IPv[4,6])

· При получении пакета (трассировка LocalDeliver IPv[4,6])

· Когда пакет отбрасывается (отбрасывает трассировки IPv[4,6])

Поскольку пакеты отслеживаются на уровне IP, любая повторная передача, вызванная протоколами L4,
(например, TCP) будет восприниматься зондом как новый пакет.

Тег будет добавлен к пакету (ns3::IPv[4,6]FlowProbeTag). Тег будет содержать основные
данные пакета, полезные для классификации пакета.

Следует подчеркнуть, что пока классифицируются только пакеты L4 (TCP, UDP). Кроме того,
будут классифицироваться только одноадресные пакеты. Эти ограничения могут быть сняты в будущем.

Данные, собранные для каждого потока:

· timeFirstTxPacket: когда был передан первый пакет в потоке;

· timeLastTxPacket: когда был передан последний пакет в потоке;

· timeFirstRxPacket: когда первый пакет в потоке был получен конечным узлом;

· timeLastRxPacket: когда был получен последний пакет в потоке;

· delaySum: сумма всех сквозных задержек для всех полученных пакетов потока;

· jitterSum: сумма всех сквозных значений джиттера задержки (вариации задержки) для всех
полученные пакеты потока, как определено в RFC 3393;

· txBytes, txPackets: общее количество переданных байт/пакетов за поток;

· rxBytes, rxPackets: общее количество полученных байт/пакетов для потока;

· lostPackets: общее количество пакетов, которые предположительно потеряны (не сообщается более 10 раз).
секунды);

· timesForwarded: количество сообщений о переадресации пакета;

· delayHistogram, jitterHistogram, packageSizeHistogram: версии гистограммы для задержки,
джиттер и размеры пакетов соответственно;

· packagesDropped, bytesDropped: количество потерянных пакетов и байтов, разделенное по
код причины пропажи (определяется в зонде).

Стоит отметить, что зонды измеряют байты пакета, включая заголовки IP.
Заголовки L2 не включаются в меру.

Эта статистика будет записана в формате XML по запросу (см. раздел «Использование»).

Рекомендации
[ПотокМонитор]

Г. Карнейро, П. Фортуна и М. Рикардо. 2009. FlowMonitor: система мониторинга сети.
для сетевого тренажера 3 (НС-3). В материалах Четвертого Международного ИКСТ
Конференция по методологиям и инструментам оценки эффективности (VALUETOOLS '09).
http://dx.doi.org/10.4108/ICST.VALUETOOLS2009.7493

Применение
Использование модуля предельно просто. Помощник позаботится обо всем.

Типичное использование:

// Монитор потока
Птр монитор потока;
FlowMonitorHelper FlowHelper;
flowMonitor = flowHelper.InstallAll();

Simulator::Stop (Секунды(stop_time));
Симулятор :: Беги ();

flowMonitor->SerializeToXmlFile("NameOfFile.xml", правда, правда);

Сериализетоксмлфиле () 2-й и 3-й параметры функции используются соответственно для
активировать/деактивировать гистограммы и подробную статистику по каждому датчику.

Другие возможные альтернативы можно найти в документации Doxygen.

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

Одна важная вещь: ns3:: FlowMonitorHelper должен быть создан только один раз в
основной.

Атрибуты
Модуль предоставляет следующие атрибуты в ns3:: FlowMonitor:

· MaxPerHopDelay (время, по умолчанию 10 с): максимальная задержка на переход, которую следует учитывать;

· StartTime (Время, по умолчанию 0 с): Время начала мониторинга;

· DelayBinWidth (двойной, по умолчанию 0.001): Ширина, используемая в гистограмме задержки;

· JitterBinWidth (двойной, по умолчанию 0.001): ширина, используемая в гистограмме джиттера;

· PacketSizeBinWidth (двойной, по умолчанию 20.0): ширина, используемая в гистограмме packetSize;

· FlowInterruptionsBinWidth (двойное значение, по умолчанию 0.25): ширина, используемая в
гистограмма прерываний потока;

· FlowInterruptionsMinTime (двойной, по умолчанию 0.5): минимальное время между прибытиями,
считается прерыванием потока.

Результат
Основной вывод модели — отчет в формате XML о статистике потоков. Пример:




























Выходные данные были сгенерированы потоком TCP от 10.1.3.1 до 10.1.2.2.

Стоит заметить, что датчик индекса 2 сообщает о большем количестве пакетов и большем количестве байтов, чем
остальные проблемы. Это совершенно нормальное поведение, так как пакеты фрагментируются по IP.
уровень в этом узле.

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

Примеры
Примеры находятся в src/flow-monitor/примеры.

Более того, в следующих примерах используется модуль Flow-Monitor:

· примеры/matrix-topology/matrix-topology.cc

· примеры/маршрутизация/manet-routing-compare.cc

· примеры/маршрутизация/simple-global-routing.cc

· примеры/tcp/tcp-варианты-comparison.cc

· примеры/беспроводной/мультирейт.cc

· example/wireless/wifi-hidden-terminal.cc

УСТРАНЕНИЕ НЕПОЛАДОК
Не определяйте более одного ns3:: FlowMonitorHelper в симуляции.

Проверка
Документ в справочных материалах содержит полное описание проверки модуля на соответствие
тестовая сеть.

Предусмотрены тесты для обеспечения правильной работы гистограммы.

ИНТЕРНЕТ МОДЕЛИ

Интернет Стек
Интернет стек агрегирование
Голый класс Узел не очень полезен как есть; другие объекты должны быть объединены с ним, чтобы
обеспечивают полезную функциональность узла.

Команда нс-3 каталог исходного кода источник/интернет обеспечивает реализацию TCP/IPv4- и
Компоненты, связанные с IPv6. К ним относятся IPv4, ARP, UDP, TCP, IPv6, обнаружение соседей и
другие сопутствующие протоколы.

Интернет-узлы не являются подклассами класса Node; это просто узлы, у которых есть
куча объектов, связанных с IP, объединенных с ними. Их можно собрать вручную или с помощью
вспомогательная функция Интернетстекхелпер:: Установить () который делает следующее для всех узлов
передается в качестве аргументов:

аннулировать
InternetStackHelper::Install (Ptr узел) константа
{
если (m_ipv4Enabled)
{
/* стек IPv4 */
если (узел->ПолучитьОбъект () != 4)
{
NS_FATAL_ERROR ("InternetStackHelper::Install()): Агрегирование "
"InternetStack к узлу с существующим объектом Ipv4");
вернуться;
}

CreateAndAggregateObjectFromTypeId (узел, "ns3::ArpL3Protocol");
CreateAndAggregateObjectFromTypeId (узел, "ns3::Ipv4L3Protocol");
CreateAndAggregateObjectFromTypeId (узел, "ns3::Icmpv4L4Protocol");
// Установить маршрутизацию
Ptr ipv4 = узел-> GetObject ();
Птр ipv4Routing = m_routing->Создать (узел);
ipv4->SetRoutingProtocol (ipv4Routing);
}

если (m_ipv6Enabled)
{
/* стек IPv6 */
если (узел->ПолучитьОбъект () != 6)
{
NS_FATAL_ERROR ("InternetStackHelper::Install()): Агрегирование "
"InternetStack к узлу с существующим объектом Ipv6");
вернуться;
}

CreateAndAggregateObjectFromTypeId (узел, "ns3::Ipv6L3Protocol");
CreateAndAggregateObjectFromTypeId (узел, "ns3::Icmpv6L4Protocol");
// Установить маршрутизацию
Ptr ipv6 = узел-> GetObject ();
Птр ipv6Routing = m_routingv6->Создать (узел);
ipv6->SetRoutingProtocol (ipv6Routing);

/* регистрация расширений и параметров IPv6 */
ipv6->RegisterExtensions ();
ipv6->Параметры регистрации ();
}

если (m_ipv4Enabled || m_ipv6Enabled)
{
/* Стеки UDP и TCP */
CreateAndAggregateObjectFromTypeId (узел, "ns3::UdpL4Protocol");
node->AggregateObject (m_tcpFactory.Create ());
Птр Фабрика = СоздатьОбъект ();
node->AggregateObject (фабрика);
}
}

Если существует несколько реализаций в нс-3 (TCP, IP-маршрутизация), эти объекты добавляются
фабричным объектом (TCP) или помощником маршрутизации (m_routing).

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

void InternetStackHelper::Initialize()
{
SetTcp("ns3::TcpL4Protocol");
Ipv4StaticRoutingHelper staticRouting;
Ipv4GlobalRoutingHelper globalRouting;
Ipv4ListRoutingСписок помощниковRouting;
Ipv6ListRoutingHelper listRoutingv6;
Ipv6StaticRoutingHelper staticRoutingv6;
listRouting.Add(staticRouting, 0);
listRouting.Add(globalRouting, -10);
listRoutingv6.Add(staticRoutingv6, 0);
SetRoutingHelper (списокRouting);
SetRoutingHelper (listRoutingv6);
}

По умолчанию IPv4 и IPv6 включены.

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

Слой-3 протоколы
На самом нижнем уровне, над сетевыми устройствами, находятся протоколы «уровня 3», в том числе
IPv4, IPv6, ARP и так далее. Класс Протокол IPv4L3 это класс реализации, чей
общедоступный интерфейс обычно является классом Ipv4, но также используется публичный API Ipv4L3Protocol
внутренне в настоящее время.

В классе Ipv4L3Protocol один метод, описанный ниже, Получаете ():

/ **
* Нижний уровень вызывает этот метод после вызова L3Demux::Lookup
* Подкласс ARP должен знать, от какого NetDevice это
* пакет приходит:
* - внедрить кэш ARP для каждого NetDevice
* - отправлять ответы arp на нужное устройство
*/
недействительным получить (Ptr устройство, ПТР p, протокол uint16_t,
const Address &from, const Address &to, NetDevice::PacketType packageType);

Во-первых, обратите внимание, что Получаете () функция имеет сигнатуру, совпадающую с ReceiveCallback
в классе Узел. Этот указатель функции вставляется в обработчик протокола узла, когда
ДобавитьИнтерфейс () называется. Фактическая регистрация выполняется с помощью заявления, такого как
следующим образом:

RegisterProtocolHandler ( MakeCallback (&Ipv4Protocol::Receive, ipv4),
Ipv4L3Protocol::PROT_NUMBER, 0);

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

Птр ipv4 = m_node->ПолучитьОбъект ();
если (ipv4 != 0)
{
ipv4->Отправить (пакет, саддр, папдр, PROT_NUMBER);
}

Этот класс прекрасно демонстрирует две техники, которые мы используем в нс-3 связывать объекты вместе:
обратные вызовы и агрегация объектов.

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

аннулировать
Ipv4L3Protocol::LocalDeliver (Ptr пакет, Ipv4Header const&ip, uint32_t iif)

Первый шаг — найти правильный объект Ipv4L4Protocol на основе номера IP-протокола.
Например, TCP зарегистрирован в демультиплексоре как протокол номер 6. Наконец, Получать()
функция на Ipv4L4Protocol (например, TcpL4Protocol:: Получить называется.

Мы еще не представили класс Ipv4Interface. По сути, каждое NetDevice сопряжено
с IPv4-представлением такого устройства. В Linux этот класс Ipv4Интерфейс около
соответствует структура in_device; основная цель - предоставить семейство адресов
конкретная информация (адреса) об интерфейсе.

Все классы имеют соответствующие трассировки для отслеживания отправленных, полученных и потерянных пакетов.
Пользователям рекомендуется использовать их, чтобы узнать, был ли отброшен пакет (и где). А
распространенной ошибкой является забывание о влиянии локальных очередей при отправке пакетов, т.е.
ARP-очередь. Это может вызвать особое недоумение при отправке больших пакетов или пакетов пакетов.
используя УДП. Очередь ожидания кэша ARP ограничена (3 дейтаграммы), и IP-пакеты могут быть
фрагментированы, что может привести к переполнению размера очереди кэша ARP. В таких случаях полезно
увеличьте размер ожидаемого кэша ARP до правильного значения, например:

Config::SetDefault("ns3::ArpCache::PendingQueueSize", UintegerValue (MAX_BURST_SIZE/L2MTU*3));

Реализация IPv6 следует аналогичной архитектуре. Узлы с двойным стеком (один с
поддержка как IPv4, так и IPv6) позволит сокету IPv6 принимать соединения IPv4 в качестве
стандартная двухуровневая система. Связанный сокет и прослушивание конечной точки IPv6 могут
получит соединение IPv4 и вернет удаленный адрес как адрес, сопоставленный с IPv4.
Поддержка параметра сокета IPV6_V6ONLY в настоящее время не существует.

Слой-4 протоколы и розетки
Далее мы опишем, как транспортные протоколы, сокеты и приложения связаны друг с другом. В
Таким образом, каждая реализация транспортного протокола представляет собой фабрику сокетов. Приложение, которое
нужна новая розетка

Например, для создания сокета UDP приложение должно использовать фрагмент кода, такой как
следующие:

Птр udpSocketFactory = ПолучитьУзел()->ПолучитьОбъект ();
Птр m_socket = socketFactory->CreateSocket ();
m_socket->Привязать (m_local_address);
...

Вышеупомянутое запросит узел, чтобы получить указатель на его фабрику сокетов UDP, создаст один
такой сокет, и будет использовать сокет с API, похожим на API сокетов на основе C, например
as Объединяйтесь () и Отправьте (). Адрес передан в связующее вещество (), Объединяйтесь () или Отправьте ()
функции могут быть IPv4-адрес, IPv6-адрес или Адрес, Если Адрес проходит и
содержит что-либо, кроме IPv4-адрес or IPv6-адрес, эти функции вернут
ошибка. В связующее вещество (пустота) и Привязать6 (пустота) функции связываются с "0.0.0.0" и "::"
соответственно.

Сокет также может быть привязан к определенному сетевому устройству, хотя Биндтонетдевайс
(Птр сетевое устройство) функции. Биндтонетдевайс (Птр сетевое устройство) свяжет
сокет на "0.0.0.0" и "::" (эквивалентно вызову связующее вещество () и Привязать6 (), если только
сокет уже привязан к определенному адресу. Подводя итог, правильная последовательность
это:

Птр udpSocketFactory = ПолучитьУзел()->ПолучитьОбъект ();
Птр m_socket = socketFactory->CreateSocket ();
m_socket->BindToNetDevice (n_netDevice);
...

или:

Птр udpSocketFactory = ПолучитьУзел()->ПолучитьОбъект ();
Птр m_socket = socketFactory->CreateSocket ();
m_socket->Привязать (m_local_address);
m_socket->BindToNetDevice (n_netDevice);
...

Следующее вызывает ошибку:

Птр udpSocketFactory = ПолучитьУзел()->ПолучитьОбъект ();
Птр m_socket = socketFactory->CreateSocket ();
m_socket->BindToNetDevice (n_netDevice);
m_socket->Привязать (m_local_address);
...

См. Главу о нс-3 розетки для получения дополнительной информации.

До сих пор мы описывали фабрику сокетов (например, класс UDP) и сокет, который может быть
специализированный (например, класс Удпсокет). Есть еще несколько ключевых объектов, которые относятся к
специализированная задача демультиплексирования пакета в один или несколько принимающих сокетов. Ключ
объектом в этой задаче является класс Ipv4EndPointDemux. Этот демультиплексор хранит объекты
класс IPv4EndPoint. Этот класс содержит кортеж адресации/порта (локальный порт, локальный
адрес, порт назначения, адрес назначения), связанные с сокетом, и получатель
Перезвони. Этот обратный вызов получения имеет функцию приема, зарегистрированную сокетом. То
Поиск () функция Ipv4EndPointDemux возвращает список объектов Ipv4EndPoint (могут
быть списком, так как более чем один сокет может соответствовать пакету). Протокол уровня 4 копирует
пакет каждому Ipv4EndPoint и вызывает его Вперед () метод, который затем вызывает
Получаете () функция, зарегистрированная сокетом.

Проблема, возникающая при работе с API сокетов на реальных системах, заключается в необходимости
управлять чтением из сокета, используя какой-либо тип ввода-вывода (например, блокирующий, неблокирующий,
асинхронный, ...). нс-3 реализует асинхронную модель ввода-вывода сокетов; приложение
устанавливает обратный вызов для уведомления о полученных данных, готовых к чтению, и обратный вызов
вызывается транспортным протоколом, когда данные доступны. Этот обратный вызов определяется как
следующим образом:

void Socket::SetRecvCallback (Обратный вызов ,
Птр ,
константный адрес&> полученные данные);

Полученные данные передаются в буфер пакетных данных. Пример использования находится в
класс ПакетСинк:

m_socket->SetRecvCallback (MakeCallback(&PacketSink::HandleRead, this));

Подводя итог, внутри реализация UDP организована следующим образом:

· А Удпимпл класс, который реализует функциональность фабрики сокетов UDP

· А UdpL4Протокол класс, реализующий логику протокола, не зависящую от сокета

· А Удпсокетимпл класс, который реализует специфичные для сокетов аспекты UDP

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

IP-совместимый узел интерфейсы
Многие детали реализации или сами внутренние объекты узла с поддержкой IP.
объекты не отображаются в общедоступном API симулятора. Это позволяет по-разному
реализации; например, замена родного нс-3 модели с портированным стеком TCP/IP
код.

Общедоступные API-интерфейсы C++ для всех этих объектов находятся в SRC / сеть каталог
в том числе в основном:

· адрес.h

· сокет.ч

· узел.h

· пакет.ч

Обычно это объекты базового класса, которые реализуют значения по умолчанию, используемые в
реализация, реализация методов доступа для получения/установки переменных состояния, атрибутов хоста и
реализовать общедоступные методы, доступные клиентам, такие как Создать сокет.

Пример путь of a пакет
На этих двух рисунках показан пример трассировки стека того, как пакеты проходят через Интернет.
Объекты узла.
[изображение] Путь отправки пакета..UNINDENT
[изображение] Путь получения пакета..UNINDENT

IPv4
Заполнитель глава

IPv6
В этой главе описывается нс-3 Возможности и ограничения модели IPv6 вместе с ее
использование и примеры.

IPv6 модель описание
Модель IPv6 во многом повторяет реализацию Linux; реализация
неполным, так как некоторые функции IPv6 не представляют большого интереса для моделирования, и
некоторые функции IPv6 просто еще не смоделированы в нс-3.

Базовый класс Ipv6 определяет общий API, а класс Протокол IPv6L3 это актуальный
класс, реализующий протокол. Фактические классы, используемые стеком IPv6, расположены
в основном в каталоге источник/интернет.

Реализация IPv6 содержится в следующих файлах:

src/internet/model/icmpv6-header.{cc,h}
src/internet/model/icmpv6-l4-протокол.{cc,h}
src/интернет/модель/ipv6.{cc,h}
src/internet/model/ipv6-address-generator.{cc,h}
src/internet/model/ipv6-autoconfigured-prefix.{cc,h}
src/internet/model/ipv6-end-point.{cc,h}
src/internet/model/ipv6-end-point-demux.{cc,h}
src/internet/model/ipv6-extension.{cc,h}
src/internet/model/ipv6-extension-demux.{cc,h}
src/internet/model/ipv6-extension-header.{cc,h}
src/internet/model/ipv6-header.{cc,h}
src/internet/model/ipv6-interface.{cc,h}
src/internet/model/ipv6-interface-address.{cc,h}
src/интернет/модель/ipv6-l3-протокол.{cc,h}
src/internet/model/ipv6-list-routing.{cc,h}
src/internet/model/ipv6-option.{cc,h}
src/internet/model/ipv6-option-demux.{cc,h}
src/internet/model/ipv6-option-header.{cc,h}
src/internet/model/ipv6-packet-info-tag.{cc,h}
src/internet/model/ipv6-pmtu-cache.{cc,h}
src/internet/model/ipv6-raw-socket-factory.{cc,h}
src/internet/model/ipv6-raw-socket-factory-impl.{cc,h}
src/internet/model/ipv6-raw-socket-impl.{cc,h}
src/интернет/модель/ipv6-маршрут.{cc,h}
src/internet/model/ipv6-routing-protocol.{cc,h}
src/internet/model/ipv6-routing-table-entry.{cc,h}
src/internet/model/ipv6-static-routing.{cc,h}
src/internet/model/ndisc-cache.{cc,h}
src/network/utils/inet6-socket-address.{cc,h}
src/network/utils/ipv6-адрес.{cc,h}

Также некоторые помощники связаны с IPv6:

src/internet/helper/internet-stack-helper.{cc,h}
src/internet/helper/ipv6-адрес-помощник.{cc,h}
src/internet/helper/ipv6-interface-container.{cc,h}
src/internet/helper/ipv6-list-routing-helper.{cc,h}
src/internet/helper/ipv6-routing-helper.{cc,h}
src/internet/helper/ipv6-static-routing-helper.{cc,h}

Файлы моделей можно условно разделить на:

· модели протоколов (например, ipv6, ipv6-l3-протокол, icmpv6-l4-протокол и т. д.)

· модели маршрутизации (т. е. все, что содержит слово «маршрутизация» в названии)

· сокеты и интерфейсы (например, ipv6-raw-socket, ipv6-interface, ipv6-end-point и т. д.)

· вещи, связанные с адресом

· заголовки, заголовки опций, заголовки расширений и т. д.

· вспомогательные классы (например, ndisc-cache)

Применение
Следующее описание основано на использовании типичных помощников, найденных в примере кода.

IPv6 не нужно активировать на узле. он автоматически добавляется в доступные
протоколы после установки Интернет-стека.

Для того, чтобы установить IPv6 вместе с IPv4, можно использовать
ns3::ИнтернетСтакхелпер метод УстановитьIpv6StackInstall (логический включить) перед установкой
InternetStack в узлах.

Обратите внимание, что для сети, поддерживающей только IPv6 (т. е. для того, чтобы не устанавливать стек IPv4 в узле)
следует использовать ns3::ИнтернетСтакхелпер метод УстановитьIpv4StackInstall (логический включить) до
установка стека.

Например, в следующем коде узел 0 будет иметь как IPv4, так и IPv6, только узел 1.
IPv6 и узел 2 только IPv4:

Контейнер узлов n;
п.Создать (3);

InternetStackHelper Интернет;
InternetStackHelper только для Интернета версии 4;
InternetStackHelper только для Интернета версии 6;

internetV4only.SetIpv6StackInstall (ложь);
internetV6only.SetIpv4StackInstall (ложь);

Internet.Install (n.Get (0));
InternetV6only.Install (n.Get (1));
InternetV4only.Install (n.Get (2));

IPv6 адреса назначение
Чтобы использовать IPv6 в сети, первое, что нужно сделать, это назначить адреса IPv6.

Любой с поддержкой IPv6 нс-3 узел будет иметь по крайней мере одно NetDevice: ns3::LoopbackNetDevice.
Адрес петлевого устройства :: 1. Все остальные NetDevices будут иметь один или несколько IPv6.
адреса:

· Одна ссылка-локальный адрес: fe80:: интерфейс ID, Где интерфейс ID происходит от
MAC-адрес сетевого устройства.

· Ноль или более глобальных адресов, например, 2001: db8 :: 1.

Обычно первый адрес на интерфейсе будет локальным для ссылки, а глобальный
адрес(а) следующие.

Глобальные адреса IPv6 могут быть:

· назначается вручную

· автогенерируемая

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

Вручную назначенный IPv6 адреса
Это, пожалуй, самый простой и часто используемый метод. Например:

Ptr n0 = CreateObject ();
Ptr n1 = CreateObject ();
Сеть NodeContainer (n0, n1);
CsmaHelper csma;
NetDeviceContainer ndc = csma.Install(net);

NS_LOG_INFO ("Назначить адреса IPv6.");
Ipv6AddressHelper ipv6;
ipv6.SetBase(Ipv6Address("2001:db8::"), Ipv6Prefix (64));
Ipv6InterfaceContainer ic = ipv6.Assign(ndc);

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

Обратите внимание, что глобальные адреса будут получены из MAC-адреса. Как следствие,
ожидайте иметь адреса, похожие на 2001:db8::200:ff:fe00:1.

Вышеописанное можно повторить, чтобы назначить узлу более одного глобального адреса.
Однако из-за Ipv6AddressHelper одноэлементный характер, сначала следует назначить все
адреса сети, затем измените базу сети (SetBase), затем выполните новое задание.

В качестве альтернативы можно присвоить узлу определенный адрес:

Ptr n0 = CreateObject ();
Сеть NodeContainer (n0);
CsmaHelper csma;
NetDeviceContainer ndc = csma.Install(net);

NS_LOG_INFO ("Специально назначить адрес IPv6.");
Ipv6AddressHelper ipv6;
Птр устройство = ndc.Get (0);
Птр узел = устройство->GetNode();
Птр ipv6proto = узел->ПолучитьОбъект ();
int32_t если индекс = 0;
ifIndex = ipv6proto->GetInterfaceForDevice (устройство);
Ipv6InterfaceAddress ipv6Addr = Ipv6InterfaceAddress (Ipv6Address ("2001:db8:f00d:cafe::42"), Ipv6Prefix (64));
ipv6proto->AddAddress (ifIndex, ipv6Addr);

Автогенерируемая IPv6 адреса
Это достигается за счет использования протокола RADVD, реализованного классом Радвд. В
пока нет помощника для этого приложения, а использование довольно сложно (см.
примеры/ipv6/radvd.cc).

При использовании этого метода узлы будут приобретать динамически (т. е. во время моделирования)
один (или несколько) глобальных адресов в соответствии с конфигурацией RADVD. Эти адреса
будут основаны на объявленном RADVD префиксе и EUI-64 узла.

Генерируется случайным образом IPv6 адреса
В то время как реальные узлы IPv6 будут использовать случайно сгенерированные адреса для защиты конфиденциальности, нс-3 приносит
НЕ имеют этой возможности. Эта функция до сих пор не считалась интересной для
моделирование.

Дублировать Адрес обнаружение (ДМД)
Узлы будут выполнять DAD (его можно отключить с помощью Icmpv6L4Протокол атрибут). На
однако, получая DAD, узлы на него не реагируют. Как есть: реакция DAD неполная, поэтому
далеко. Основная причина заключается в отсутствующей возможности генерации случайных адресов. Кроме того,
с нс-3 узлы обычно ведут себя хорошо, дублирующих адресов быть не должно.
Это может быть изменено в будущем, чтобы избежать проблем с реальными интегрированными
моделирование.

Хозяин и Маршрутизатор поведение in IPv6 и нс-3
В IPv6 существует четкое различие между Маршрутизаторы и хостов. Как и следовало ожидать,
маршрутизаторы могут пересылать пакеты с интерфейса на другой интерфейс, в то время как хосты пропускают
пакеты, не направленные им.

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

In нс-3 узел настроен как кашель по умолчанию. Есть два основных способа изменить
это поведение:

· С использованием ns3::Ipv6InterfaceContainer SetForwarding(uint32_t i, BOOL роутер) в котором i это
индекс интерфейса в контейнере.

· Изменение ns3::IPv6 атрибут IPForward.

Любой из них может быть использован во время моделирования.

Тонкую настройку можно выполнить с помощью ns3::Ipv6Интерфейс SetForwarding (логический
вперед); что позволяет изменять поведение для каждого интерфейса.

Обратите внимание, что конфигурация на уровне узла служит только удобным способом включения/отключения
ns3::Ipv6Интерфейс конкретная настройка. Ipv6Interface добавлен к узлу с переадресацией
enable также будет настроен на пересылку. Это действительно важно, когда узел имеет
интерфейсы, добавленные во время моделирования.

Согласно ns3::Ipv6Интерфейс состояние пересылки, происходит следующее:

· Переадресация ВЫКЛ.

· Узел НЕ будет отвечать на запрос маршрутизатора

· Узел будет реагировать на объявление маршрутизатора

· Узел будет периодически отправлять Router Solicitation

· Протоколы маршрутизации ДОЛЖНЫ ОТБРАСЫВАТЬ пакеты, не направленные узлу

· Переадресация включена

· Узел ответит на запрос маршрутизатора

· Узел НЕ будет реагировать на объявление маршрутизатора

· Узел НЕ будет отправлять запрос маршрутизатора

· Протоколы маршрутизации ДОЛЖНЫ пересылать пакеты

Поведение соответствует ip-sysctl.txt (‐
http://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt) с той разницей, что
невозможно переопределить поведение с помощью эзотерических настроек (например, переадресация, но
принимать объявления маршрутизатора, accept_ra=2 или пересылать, но отправлять запросы маршрутизатора
переадресация=2).

Внимательно рассмотрите последствия пересылки пакетов. Например, узел НЕ будет
отправлять сообщения ICMPv6 PACKET_TOO_BIG с интерфейса с отключенной переадресацией. Это
совершенно нормально, так как протокол маршрутизации отбрасывает пакет перед попыткой
направить его.

Помощники
Обычно помощники, используемые при настройке IPv6:

· ns3::ИнтернетСтакхелпер

· ns3::Ipv6AddressHelper

· ns3::Ipv6InterfaceContainer

Использование почти идентично соответствующему случаю IPv4, например:

Контейнер узлов n;
п.Создать (4);

NS_LOG_INFO ("Создать Интернет-стек IPv6");
InternetStackHelper Internetv6;
интернетv6.Установить (n);

NS_LOG_INFO ("Создать каналы.");
CsmaHelper csma;
NetDeviceContainer d = csma.Install(n);

NS_LOG_INFO ("Создание сетей и назначение IPv6-адресов.");
Ipv6AddressHelper ipv6;
ipv6.SetBase(Ipv6Address("2001:db8::"), Ipv6Prefix (64));
Ipv6InterfaceContainer iic = ipv6.Assign (d);

Кроме того, распространенной задачей является включение переадресации на одном из узлов и настройка
маршрут по умолчанию к нему в других узлах, например:

iic.SetForwarding (0, правда);
iic.SetDefaultRouteInAllNodes (0);

Это позволит пересылать на узле 0 и установит маршрут по умолчанию в
ns3::Ipv6StaticRouting на всех остальных узлах. Обратите внимание, что для этого требуется, чтобы
Ipv6StaticRouting присутствует в узлах.

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

Атрибуты
Многие занятия в нс-3 Реализация IPv6 содержит атрибуты. Самые полезные из них:

· ns3::IPv6

· IPForward, логическое значение, по умолчанию false. Глобально включить или отключить IP-переадресацию для всех
текущие и будущие устройства IPv6.

· МтуДискавер, логическое значение, по умолчанию true. Если отключено, каждый интерфейс будет иметь свой MTU.
установить 1280 байт.

· ns3 :: Ipv6L3Protocol

· ДефолтТтл, uint8_t, по умолчанию 64. Значение TTL, установленное по умолчанию для всех исходящих пакетов
генерируется на этом узле.

· ОтправитьIcmpv6Redirect, логическое значение, по умолчанию true. При необходимости отправьте перенаправление ICMPv6.

· ns3::Icmpv6L4Протокол

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

· ns3::NdiscCache

· неразрешенный размер очереди, uint32_t, по умолчанию 3. Размер очереди для пакетов, ожидающих NA
Ответить.

Результат
Стек IPv6 предоставляет несколько полезных источников трассировки:

· ns3 :: Ipv6L3Protocol

· Tx, Отправить пакет IPv6 на исходящий интерфейс.

· Rx, Получите пакет IPv6 от входящего интерфейса.

· Падение, Отбросить пакет IPv6.

· ns3::Ipv6Extension

· Падение, Отбросить пакет IPv6.

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

Имейте в виду, что ns3::NdiscCache также могут отбрасывать пакеты, и они не регистрируются в трассировке
источник (пока). Это может вызвать некоторую путаницу в счетчиках отправленных/полученных пакетов.

Фильтр Применение
IPv6 максимальный в мозге Ед. изм (MTU), и фрагментация
нс-3 NetDevices определяют MTU в соответствии с имитируемым устройством L2. IPv6 требует, чтобы
минимальный MTU составляет 1280 байт, поэтому все NetDevices должны поддерживать как минимум этот
МТУ. Это ссылка-MTU.

Для поддержки разных MTU на пути источник-назначение нс-3 Модель IPv6 может
выполнить фрагментацию. Это может быть вызвано получением пакета большего размера, чем
link-MTU из протоколов L4 (UDP, TCP и т. д.) или путем получения пакета ICMPv6 PACKET_TOO_BIG.
сообщение. Модель имитирует RFC 1981 со следующими заметными исключениями:

· Протоколы L4 не информируются об изменении Path MTU

· TCP не может изменить свой размер сегмента в соответствии с Path-MTU.

Оба ограничения будут сняты в свое время.

Кэш Path-MTU в настоящее время основан на IPv6-адресах источника и назначения. Дальше
классификации (например, метка потока) возможны, но еще не реализованы.

Время действия Path-MTU по умолчанию составляет 10 минут. После истечения срока действия записи кэша
Информация о пути-MTU удаляется, и следующий пакет (в конечном счете) инициирует новый протокол ICMPv6.
Сообщение PACKET_TOO_BIG. Обратите внимание, что 1) это соответствует спецификации RFC и 2)
Протоколы L4 отвечают за повторную передачу пакетов.

Примеры
Примеры для IPv6 находятся в каталоге примеры/ipv6. Эти примеры касаются наиболее
интересные особенности IPv6, такие как фрагментация, перенаправление и т.д.

Более того, большинство примеров TCP и UDP, расположенных в примеры/udp, примеры/tcpи т. д. имеют
параметр командной строки для использования IPv6 вместо IPv4.

УСТРАНЕНИЕ НЕПОЛАДОК
Есть только несколько подводных камней, которых следует избегать при использовании нс-3 IPv6.

Маршрутизация петли
Поскольку единственная (пока) схема маршрутизации, доступная для IPv6, ns3::Ipv6StaticRouting,
маршрутизатор по умолчанию должен быть настроен вручную. Когда в сети два или более маршрутизатора
(например, узел A и узел B), избегайте использования вспомогательной функции Сетдефаултроутеиналлнодес для
более одного маршрутизатора.

Следствием этого будет установка маршрута по умолчанию к B в A и маршрута по умолчанию, указывающего
к A в B, создавая петлю.

Глобальный адрес утечка
Помните, что адреса в IPv6 Глобальный по определению. При использовании IPv6 с
эмуляция нс-3 возможность любой ценой избежать утечки адресов в глобальный Интернет.
Рекомендуется установить внешний брандмауэр, чтобы предотвратить утечку.

2001: DB8:: / 32 адреса
Стандарт IPv6 (RFC 3849) определяет 2001: DB8:: / 32 адресный класс для документации.
В данном руководстве используется это соглашение. Однако адреса этого класса можно использовать только в
документ, и маршрутизаторы должны отбросить их.

Проверка
Протоколы IPv6 еще не были тщательно проверены на соответствие реальным реализациям.
Фактические тесты включают в себя в основном проверку файлов трассировки .pcap с помощью Wireshark,
и результаты положительные.

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

Маршрутизация архитектура
[изображение] Обзор маршрутизации.UNINDENT

Обзор of маршрутизация показывает общую архитектуру маршрутизации для IPv4. Ключевыми объектами являются
Ipv4L3Protocol, Ipv4RoutingProtocol(s) (класс, к которому относится вся маршрутизация/переадресация).
делегированы из Ipv4L3Protocol) и Ipv4Route(s).

Ipv4L3Protocol должен иметь по крайней мере один Ipv4RoutingProtocol, добавленный к нему при моделировании.
время установки. Это делается явно вызовом Ipv4::SetRoutingProtocol().

Абстрактный базовый класс Ipv4RoutingProtocol() объявляет минимальный интерфейс, состоящий
из двух методов: RouteOutput() и RouteInput(). Для пакетов, исходящих из
хост, транспортный протокол запросит у IPv4 объект Ipv4RoutingProtocol.
интерфейс, и будет запрашивать маршрут через Ipv4RoutingProtocol::RouteOutput(). Ptr для
Возвращается объект Ipv4Route. Это аналогично записи dst_cache в Linux. То
Ipv4Route переносится в Ipv4L3Protocol, чтобы избежать второго поиска там. Тем не мение,
в некоторых случаях (например, необработанные сокеты IPv4) потребуется вызов RouteOutput() непосредственно из
IPv4L3Протокол.

Для входящих пакетов, полученных для пересылки или доставки, выполняются следующие действия.
Ipv4L3Protocol::Receive() вызывает Ipv4RoutingProtocol::RouteInput(). Это проходит
владение пакетом объекту Ipv4RoutingProtocol. Есть четыре обратных вызова, связанных
с этим вызовом:

· Местная доставка

· Одноадресная передача

· Многоадресная рассылка

· Ошибка

В конечном итоге Ipv4RoutingProtocol должен вызывать один из этих обратных вызовов для каждого пакета, который
он берет на себя ответственность. Это в основном то, как работает процесс маршрутизации входных данных в
Linux.
[изображение] Специализация Ipv4Routing.. UNINDENT

Эта общая архитектура предназначена для поддержки различных подходов к маршрутизации, включая
(в будущем) подобная Linux реализация маршрутизации на основе политик, проактивная и
протоколы маршрутизации по требованию и простые протоколы маршрутизации, когда пользователь моделирования
на самом деле не заботится о маршрутизации.

IPv4Routing специализация. иллюстрирует, как из этого вытекают несколько протоколов маршрутизации.
базовый класс. Класс Ipv4ListRouting (класс реализации Ipv4ListRoutingImpl) предоставляет
существующий подход маршрутизации списка в нс-3. Его API такой же, как у базового класса
Ipv4Routing, за исключением возможности добавления нескольких приоритетных протоколов маршрутизации.
(Ipv4ListRouting::AddRoutingProtocol(), Ipv4ListRouting::GetRoutingProtocol()).

Подробности этих протоколов маршрутизации описаны ниже в одноадресный маршрутизация. Теперь,
сначала мы начнем с базовой возможности одноадресной маршрутизации, предназначенной для глобального
создавать таблицы маршрутизации во время моделирования t=0 для пользователей моделирования, которые не заботятся о
динамическая маршрутизация.

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

· Проводная только: Он не предназначен для использования в беспроводных сетях.

· одноадресный только: Он не делает многоадресную рассылку.

· Масштаб: Некоторые пользователи больших топологий (например, 1000 узлов) заметили, что
текущая реализация не очень масштабируема. Глобальная централизованная маршрутизация будет
изменены в будущем для уменьшения вычислений и производительности во время выполнения.

В настоящее время глобальная централизованная одноадресная маршрутизация IPv4 как по точкам, так и по
(CSMA) ссылки поддерживаются.

По умолчанию при использовании нс-3 вспомогательный API и InternetStackHelper по умолчанию, глобальный
возможность маршрутизации будет добавлена ​​к узлу, а глобальная маршрутизация будет вставлена ​​как
протокол маршрутизации с более низким приоритетом, чем статические маршруты (т. е. пользователи могут вставлять маршруты
через Ipv4StaticRouting API, и они будут иметь приоритет над маршрутами, найденными глобальными
маршрутизация).

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

#include "ns3 / internet-module.h"

Если используется InternetStackHelper по умолчанию, экземпляр глобальной маршрутизации будет
объединены в каждый узел. После настройки IP-адресов следующий вызов функции
приведет к тому, что все узлы, имеющие интерфейс Ipv4, получат таблицы переадресации.
вводится автоматически GlobalRouteManager:

Ipv4GlobalRoutingHelper :: PopulateRoutingTables ();

Примечание: Напоминание о том, что Wi-Fi NetDevice будет работать, но не будет иметь никаких эффектов беспроводной связи.
в учетную запись. Для беспроводной сети мы рекомендуем динамическую маршрутизацию OLSR, описанную ниже.

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

Ipv4GlobalRoutingHelper::RecomputeRoutingTables ();

который сбрасывает старые таблицы, запрашивает у узлов информацию о новом интерфейсе и
восстанавливает маршруты.

Например, этот вызов планирования вызовет перестроение таблиц через 5 секунд:

Симулятор::Расписание (Секунды (5),
&Ipv4GlobalRoutingHelper::RecomputeRoutingTables);

Есть два атрибута, которые управляют поведением. Первый
Ipv4GlobalRouting::RandomEcmpRouting. Если установлено значение true, пакеты будут маршрутизироваться случайным образом.
многопутевые маршруты с равной стоимостью. Если установлено значение false (по умолчанию), постоянно используется только один маршрут.
использовал. Второй — Ipv4GlobalRouting::RespondToInterfaceEvents. Если установлено значение true,
динамически пересчитывать глобальные маршруты при событиях уведомления интерфейса (вверх/вниз или
добавить/удалить адрес). Если установлено значение false (по умолчанию), маршрутизация может прерваться, если только пользователь не
вызывает RecomputeRoutingTables() после таких событий. По умолчанию установлено значение false, чтобы сохранить
наследие нс-3 поведение программы.

Глобальный Маршрутизация Реализация
Этот раздел предназначен для тех читателей, которым небезразлично, как это реализовано. синглтон
объект (GlobalRouteManager) отвечает за заполнение статических маршрутов на каждом узле,
используя общедоступный API Ipv4 этого узла. Он запрашивает каждый узел в топологии для
Интерфейс "глобальный маршрутизатор". Если он найден, он использует API этого интерфейса для получения «ссылки
объявление о состоянии (LSA)» для маршрутизатора. Объявления о состоянии канала используются в OSPF.
маршрутизация, и мы следим за их форматированием.

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

GlobalRouteManager заполняет базу данных состояния канала LSA, собранными со всего
топология. Затем для каждого маршрутизатора в топологии GlobalRouteManager выполняет OSPF.
вычисление кратчайшего пути (SPF) в базе данных и заполнение таблиц маршрутизации на
каждый узел.

квагга (англ.http://www.quagga.net) В качестве основы для
логика расчета маршрутизации. Одним из преимуществ использования существующей реализации OSPF SPF является
что OSPF уже определил объявления о состоянии канала для всех распространенных типов сетей.
слева направо:

· точка-точка (последовательные ссылки)

· точка-многоточка (Frame Relay, одноранговая беспроводная связь)

· нешироковещательный множественный доступ (ATM)

· широковещательная передача (Ethernet)

Поэтому мы считаем, что включение этих других типов ссылок теперь будет более простым.
наличие базовой структуры OSPF SPF.

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

GlobalRouteManager сначала просматривает список узлов и агрегирует GlobalRouter.
интерфейс к каждому из них следующим образом:

typedef std::vector < Ptr >::итератор Итератор;
for (Итератор i = NodeList::Begin (); i != NodeList::End (); i++)
{
Птр узел = * я;
Птр globalRouter = СоздатьОбъект (узел);
node->AggregateObject (globalRouter);
}

Позже этот интерфейс запрашивается и используется для создания объявления о состоянии канала для каждого
маршрутизатор, и эта база данных состояния канала передается в логику вычисления кратчайшего пути OSPF.
Наконец, API Ipv4 используется для заполнения самих маршрутов.

одноадресный маршрутизация
В настоящее время для IPv4 определено семь протоколов одноадресной маршрутизации и три для IPv6:

· класс Ipv4StaticRouting (охватывающий как одноадресную, так и многоадресную рассылку)

· IPv4 Оптимизированная маршрутизация состояния канала (OLSR) (протокол MANET, определенный в RFC 3626)

· IPv4 Ad Hoc On Demand Distance Vector (AODV) (протокол MANET, определенный в RFC 3561)

· IPv4 Destination Sequenced Distance Vector (DSDV) (протокол MANET)

· Динамическая маршрутизация источника IPv4 (DSR) (протокол MANET)

· класс Ipv4ListRouting (используется для хранения приоритетного списка протоколов маршрутизации)

· класс Ipv4GlobalRouting (используется для хранения маршрутов, рассчитанных менеджером глобальных маршрутов, если
что используется)

· класс Ipv4NixVectorRouting (более эффективная версия глобальной маршрутизации, хранящая
исходные маршруты в поле заголовка пакета)

· класс Ipv6ListRouting (используется для хранения приоритетного списка протоколов маршрутизации)

· класс Ipv6StaticRouting

· class RipNg - протокол IPv6 RIPng (RFC 2080)

В будущем эта архитектура также должна позволить кому-то реализовать Linux-подобную систему.
реализация с кешем маршрутизации или модульным маршрутизатором Click, но это выходит за рамки
на данный момент.

IPv[4,6]ListRouting
В этом разделе описывается текущее значение по умолчанию. нс-3 IPv[4,6]Протокол маршрутизации. Как правило,
несколько протоколов маршрутизации поддерживаются в пользовательском пространстве и координируются для записи одного
таблица переадресации в ядре. В настоящее время в нс-3, вместо этого реализация позволяет
несколько протоколов маршрутизации для построения/сохранения собственного состояния маршрутизации и IP
реализация будет запрашивать каждый из этих протоколов маршрутизации (в порядке, определяемом
автор моделирования) до тех пор, пока маршрут не будет найден.

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

IPv[4,6]4ListRouting::AddRoutingProtocol
Классы Ipv4ListRouting и Ipv6ListRouting предоставляют объявление чистой виртуальной функции.
для метода, позволяющего добавить протокол маршрутизации:

void AddRoutingProtocol (Ptr протокол маршрутизации,
int16_t приоритет);

void AddRoutingProtocol (Ptr протокол маршрутизации,
int16_t приоритет);

Эти методы реализованы соответственно классом Ipv4ListRoutingImpl и классом
Ipv6ListRoutingImpl в интернет-модуле.

Указанная выше переменная приоритета определяет приоритет протоколов маршрутизации.
вставлен. Обратите внимание, что это подписанный int. По умолчанию в нс-3, вспомогательные классы будут
создайте экземпляр объекта Ipv[4,6]ListRoutingImpl и добавьте к нему Ipv[4,6]StaticRoutingImpl
объект с нулевым приоритетом. Внутри хранится список Ipv[4,6]RoutingProtocols, и
и протоколы маршрутизации консультируются с каждым в порядке убывания приоритета, чтобы увидеть
найдено ли совпадение. Поэтому, если вы хотите, чтобы ваш Ipv4RoutingProtocol имел приоритет
ниже статической маршрутизации, вставляйте ее с приоритетом меньше 0; например:

Птр myRoutingProto = СоздатьОбъект ();
listRoutingPtr->AddRoutingProtocol (myRoutingProto, -10);

При вызовах RouteOutput() или RouteInput() объект маршрутизации списка будет искать в списке
протоколов маршрутизации в порядке приоритета, пока маршрут не будет найден. Такой протокол маршрутизации
вызовет соответствующий обратный вызов, и дальнейший поиск протоколов маршрутизации выполняться не будет.

Оптимизированный Ссылка Область Маршрутизация (ОЛСР)
Этот протокол маршрутизации IPv4 изначально был перенесен из реализации OLSR-UM для ns-2.
Реализация находится в каталоге src/olsr, а пример скрипта находится в
примеры/простой-точка-точка-olsr.cc.

Обычно OLSR активируется в основной программе с помощью класса OlsrHelper, который устанавливает
OLSR в объект Ipv4ListRoutingProtocol. Следующие примеры команд позволят
OLSR в моделировании с использованием этого вспомогательного класса вместе с некоторыми другими вспомогательными объектами маршрутизации.
Установка значения приоритета 10 перед приоритетом staticRouting, равным 0, означает, что
OLSR будет запрашивать маршрут перед таблицей статической маршрутизации узла.:

Контейнер узла c:
...
// Включить ОЛСР
NS_LOG_INFO ("Включение маршрутизации OLSR.");
Олсрхелпер olsr;

Ipv4StaticRoutingHelper staticRouting;

список Ipv4ListRoutingHelper;
list.Add(staticRouting, 0);
список.Добавить(olsr, 10);

InternetStackHelper Интернет;
internet.SetRoutingHelper (список);
Интернет.Установить (с);

После установки «основной интерфейс» OLSR можно настроить с помощью команды SetMainInterface().
Если пользователь не укажет основной адрес, протокол выберет первый основной IP-адрес.
адрес, который он находит, запуская сначала петлевой интерфейс, а затем следующий
Найден интерфейс без обратной связи, в порядке индекса интерфейса Ipv4. петлевой адрес
127.0.0.1 не выбран. Кроме того, ряд констант протокола определен в
olsr-routing-protocol.cc.

Olsr запускается в нулевое время моделирования на основе вызова Object::Start(), который
в конечном итоге вызывает OlsrRoutingProtocol::DoStart(). Примечание: патч, позволяющий пользователю запускать
и остановка протокола в другое время приветствуется.

В настоящее время OLSR может использоваться только с объектом Ipv4ListRouting и не отвечает на
динамические изменения IP-адреса устройства или уведомления о подключении/отключении; т.е. топология
изменения происходят из-за потери/получения возможности подключения по беспроводному каналу.

RIPng
Этот протокол маршрутизации IPv6 (RFC 2080) представляет собой эволюцию хорошо известных протоколов RIPv1 и RIPv2.
(См. RFC 1058 и RFC 1723) протоколы маршрутизации для IPv4.

Протокол очень прост и обычно подходит для плоской, простой сети.
топологий.

RIPng в значительной степени основан на RIPv1 и RIPv2 и имеет те же самые цели и возможности.
ограничения. В частности, RIP рассматривает любой маршрут с метрикой, равной или превышающей 16.
как недосягаемый. Как следствие, максимальное количество переходов в сети должно быть меньше
чем 15 (количество роутеров не задано). Пользователям предлагается прочитать RFC 2080 и RFC
1058 чтобы полностью понять поведение и ограничения RIPng.

Маршрутизация сходимость
RIPng использует алгоритм вектора расстояния, и маршруты обновляются в соответствии с
Алгоритм Беллмана-Форда (иногда известный как алгоритм Форда-Фалкерсона). Алгоритм имеет
время сходимости O(|V|*|E|), где |V| и |Е| количество вершин (маршрутизаторов) и
ребра (звенья) соответственно. Следует подчеркнуть, что время сходимости есть число
шагов в алгоритме, и каждый шаг запускается сообщением. С момента запуска
Обновления (т.е. при изменении маршрута) имеют время восстановления 1-5 секунд, топология может
требуется некоторое время для стабилизации.

Пользователи должны знать, что во время построения таблиц маршрутизации маршрутизаторы могут
пакеты. Трафик данных следует отправлять только по прошествии времени, достаточного для создания RIPng.
топология сети. Обычно 80 секунд должно быть достаточно для субоптимального (но
работает) настройка маршрутизации. Сюда входит время, необходимое для распространения маршрутов до самых
удаленный маршрутизатор (16 переходов) с инициированными обновлениями.

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

Пример примеры/маршрутизация/ripng-simple-network.cc показывает настройку сети и
этапы восстановления сети.

Split Горизонт
Split Horizon — это стратегия предотвращения нестабильности маршрутизации. Возможны три варианта:

· Нет разделения горизонта

· Разделить горизонт

· Обратный яд

В первом случае маршруты объявляются на всех интерфейсах маршрутизатора. Во-вторых
В этом случае маршрутизаторы не будут объявлять маршрут на интерфейсе, из которого он был получен.
Poison Reverse объявит маршрут на интерфейсе, из которого он был получен, но
с метрикой 16 (бесконечность). Полный анализ трех методов см. RFC
1058, раздел 2.2.

Пример ripng-простой-network.cc основан на топологии сети, описанной в RFC,
но он не показывает описанный там эффект.

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

Однако в сложных топологиях все еще возможны явления нестабильности маршрута.
аналогично описанному в RFC после сбоя соединения. Как следствие, все
соображения о разделении горизонта остаются в силе.

По умолчанию маршруты
Должен быть установлен протокол RIPng Важно на роутерах. Как следствие, узлы не будут знать
какой роутер по умолчанию.

Чтобы обойти это ограничение, пользователи должны либо установить маршрут по умолчанию вручную (например,
прибегая к Ipv6StaticRouting) или используя RADVd. RADVd доступен в нс-3 в
Модуль приложений, и это настоятельно рекомендуется.

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

Кроме того, пользователи могут изменять метрики интерфейса для каждого узла.

Тип Split Horizoning (чтобы избежать обратного распространения маршрутов) можно выбрать на
для каждого узла, с вариантами выбора: «без разделения горизонта», «разделение горизонта» и «отравление
реверс". См. RFC 2080 для получения дополнительной информации и RFC 1058 для полноценного обсуждения
стратегии разделения горизонта.

ограничения
Опция Next Hop не поддерживается (RFC 2080, раздел 2.1.1). Следующий прыжок
Параметр полезен, когда RIPng не запускается на всех маршрутизаторах в сети. Служба поддержки
так как этот вариант может быть рассмотрен в будущем.

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

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

аннулировать
Ipv4StaticRouting::AddMulticastRoute (источник IPv4Address,
группа IPv4Address,
uint32_t интерфейс ввода,
станд::вектор выходные интерфейсы);

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

Обычно существует два основных типа многоадресных маршрутов: используются маршруты первого типа
во время переадресации. Все условия должны быть указаны явно. Второй вид
маршруты используются для получения пакетов от локального узла. Разница во входе
интерфейс. Маршруты для пересылки всегда будут иметь явный указанный входной интерфейс.
Маршруты от узла всегда будут устанавливать входной интерфейс на подстановочный знак, указанный параметром
индекс Ipv4RoutingProtocol::IF_INDEX_ANY.

Для маршрутов вне локального узла можно использовать подстановочные знаки в группе происхождения и многоадресной рассылки.
адреса. Подстановочный знак, используемый для Ipv4Adresses, — это адрес, возвращаемый
Ipv4Address::GetAny() -- обычно "0.0.0.0". Использование подстановочного знака позволяет указать
поведение по умолчанию в разной степени.

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

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

Другая команда устанавливает многоадресный маршрут по умолчанию:

аннулировать
Ipv4StaticRouting::SetDefaultMulticastRoute (uint32_t outputInterface);

Это многоадресный эквивалент одноадресной версии SetDefaultRoute. Мы говорим
система маршрутизации что делать в случае когда указан конкретный маршрут к пункту назначения многоадресной рассылки
группа не найдена. Система пересылает пакеты через указанный интерфейс в надежде, что
что «что-то там» лучше знает, как направить пакет. Этот метод используется только
при первоначальной отправке пакетов с хоста. Многоадресный маршрут по умолчанию не используется
во время пересылки -- точные маршруты должны быть указаны с помощью AddMulticastRoute для этого случая.

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

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

uint32_t GetNMulticastRoutes (недействительный) const;

Ipv4MulticastRoute *GetMulticastRoute (uint32_t i) const;

Ipv4MulticastRoute *GetDefaultMulticastRoute (void) const;

bool RemoveMulticastRoute (источник IPv4Address,
группа IPv4Address,
uint32_t интерфейс ввода);

недействительным RemoveMulticastRoute (индекс uint32_t);

TCP ухода in нс-3
В этой главе описываются модели TCP, доступные в нс-3.

Общий поддержка для TCP
нс-3 был написан для поддержки нескольких реализаций TCP. Реализации наследуются от
несколько общих классов заголовков в SRC / сеть каталог, чтобы пользовательский код мог выгружаться
реализации с минимальными изменениями в скриптах.

Есть два важных абстрактных базовых класса:

· класс TCPSocket: это определено в src/интернет/модель/tcp-сокет.{cc,h}. Этот класс
существует для размещения атрибутов TcpSocket, которые можно повторно использовать в разных
реализации. Например, атрибут НачальноеCwnd можно использовать для любого из
реализации, производные от класса TCPSocket.

· класс TcpSocketFactory: используется экземпляром протокола уровня 4 для создания TCP.
розетки нужного типа.

В настоящее время доступны три реализации TCP для нс-3.

· нативно реализованный TCP для ns-3

· поддержка Cеть Симуляторы Колыбель (НСК)

· Поддержка для Напрямую Code Исполнение (ДХЭ)

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

нс-3 TCP
До выпуска ns-3.10, нс-3 содержал порт модели TCP от GTNetS. Это
реализация была существенно переписана Адрианом Тэмом для ns-3.10. Модель является полной
TCP, поскольку он является двунаправленным и пытается смоделировать установку и закрытие соединения.
логика.

Реализация TCP содержится в следующих файлах:

src/internet/model/tcp-header.{cc,h}
src/internet/model/tcp-l4-протокол.{cc,h}
src/internet/model/tcp-socket-factory-impl.{cc,h}
src/internet/model/tcp-socket-base.{cc,h}
src/internet/model/tcp-tx-buffer.{cc,h}
src/internet/model/tcp-rx-buffer.{cc,h}
src/интернет/модель/tcp-rfc793.{cc,h}
src/интернет/модель/tcp-tahoe.{cc,h}
src/интернет/модель/tcp-reno.{cc,h}
src/internet/model/tcp-westwood.{cc,h}
src/интернет/модель/tcp-newreno.{cc,h}
src/internet/model/rtt-estimator.{cc,h}
источник/сеть/модель/порядковый номер.{cc,h}

Различные варианты управления перегрузкой TCP поддерживаются путем создания подклассов общей базы.
класс Ткпсокетбасе. Поддерживается несколько вариантов, в том числе RFC 793 (без пробок
контроль), Тахо, Рино, Вествуд, Вествуд+ и НьюРено. NewReno используется по умолчанию. Видеть
раздел «Использование» этого документа о том, как изменить вариант TCP по умолчанию, используемый в
моделирование.

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

Используя вспомогательные функции, определенные в SRC / приложения / помощник и источник/сеть/помощник, Вот
как можно было бы создать приемник TCP:

// Создаем приемник пакетов на звездообразном «хабе» для приема этих пакетов
порт uint16_t = 50000;
Адрес sinLocalAddress(InetSocketAddress(Ipv4Address::GetAny(), порт));
PacketSinkHelper;
Контейнер приложений;
sinApp.Start(Секунды (1.0));
sinApp.Stop(Секунды (10.0));

Точно так же приведенный ниже фрагмент кода настраивает источник трафика OnOffApplication для использования TCP:

// Создаем приложения OnOff для отправки TCP на сервер
OnOffHelper clientHelper("ns3::TcpSocketFactory", Address ());

Внимательный читатель заметит выше, что мы указали TypeId абстрактной базы.
класс TcpSocketFactory. Как скрипт говорит нс-3 что он хочет родной нс-3 TCP
по сравнению с каким-то другим? Что ж, когда к узлу добавляются интернет-стеки, TCP по умолчанию
реализация, объединенная с узлом, является нс-3 ПТС. Это можно переопределить как
мы показываем ниже при использовании базовой станции сетевого моделирования. Таким образом, по умолчанию при использовании нс-3
вспомогательный API, TCP, который объединяется с узлами с интернет-стеком, является родным нс-3
ПТС.

Для настройки поведения TCP ряд параметров экспортируется через нс-3
система атрибутов. Они задокументированы в Доксиген
<http://www.nsnam.org/doxygen/classns3_1_1_tcp_socket.html> для класса TCPSocket. Для
Например, максимальный размер сегмента является устанавливаемым атрибутом.

Чтобы установить тип сокета по умолчанию перед созданием каких-либо объектов, связанных с интернет-стеком, один
может поместить следующий оператор в начало программы моделирования:

Config::SetDefault("ns3::TcpL4Protocol::SocketType", StringValue("ns3::TcpTahoe"));

Для пользователей, которые хотят иметь указатель на фактический сокет (чтобы операции с сокетом, такие как
Bind(), настройка параметров сокета и т. д. может выполняться для каждого сокета), сокеты Tcp могут
быть создано с помощью Сокет:: Создать сокет() метод. TypeId передан
CreateSocket() должен быть типа ns3::SocketFactory, поэтому настройка базового сокета
тип должен быть выполнен путем изменения атрибута, связанного с базовым протоколом TcpL4Protocol.
объект. Самый простой способ получить это - настроить атрибут
система. В приведенном ниже примере доступ к контейнеру Node "n0n1" осуществляется для получения нулевого
элемент, и на этом узле создается сокет:

// Создаем и связываем сокет...
TypeId tid = TypeId::LookupByName("ns3::TcpTahoe");
Config::Set("/NodeList/*/$ns3::TcpL4Protocol/SocketType", TypeIdValue (tid));
Птр локальный сокет =
Socket::CreateSocket(n0n1.Get(0), TcpSocketFactory::GetTypeId());

Выше подстановочный знак «*» для номера узла передается в систему конфигурации атрибутов,
так что все будущие сокеты на всех узлах будут установлены на Tahoe, а не только на узле «n0n1.Get (0)».
Если кто-то хочет ограничить его только указанным узлом, нужно будет сделать что-то вроде:

// Создаем и связываем сокет...
TypeId tid = TypeId::LookupByName("ns3::TcpTahoe");
std::stringstream nodeId;
nodeId << n0n1.Get (0)->GetId ();
std::string SpecificNode = "/NodeList/" + nodeId.str () + "/$ns3::TcpL4Protocol/SocketType";
Config::Set(specificNode, TypeIdValue (tid));
Птр локальный сокет =
Socket::CreateSocket(n0n1.Get(0), TcpSocketFactory::GetTypeId());

Как только сокет TCP создан, нужно следовать обычной логике сокета и либо
connect() и send() (для TCP-клиента) или bind(), listen() и accept() (для TCP-клиента).
сервер). См. Sockets-API для обзора того, как сокеты используются в нс-3.

Проверка
Несколько результатов проверки TCP можно найти в Вики страница описывая это
реализации.

Текущий недостатки
· SACK не поддерживается

Cеть Симуляторы Колыбель
Команда Cеть Симуляторы Колыбель (НСК) это фреймворк для упаковки реального сетевого кода
в симуляторы, позволяющие имитировать поведение в реальном мире с небольшими дополнительными затратами. Этот
работа была проверена путем сравнения ситуаций с использованием тестовой сети с тем же
ситуации в симуляторе. На сегодняшний день показано, что НБК способен производить
чрезвычайно точные результаты. NSC поддерживает четыре реальных стека: FreeBSD, OpenBSD, lwIP.
и линукс. Акцент был сделан на том, чтобы не менять вручную ни один из сетевых стеков. Нет
одна строка кода была изменена в реализациях сетевого протокола любого из
вышеупомянутые четыре стека. Однако для программного изменения был создан специальный парсер C.
исходный код.

Ранее NSC был перенесен на нс-2 и OMNeT++, и был добавлен в нс-3 в сентябре
2008 г. (выпуск ns-3.2). В этом разделе описывается нс-3 порт NSC и как его использовать.

В какой-то степени NSC был заменен поддержкой ядра Linux в рамках Напрямую Code
Типы (ДХЭ). Тем не менее, NSC по-прежнему доступен через систему сборки запекания. НБК
поддерживает ядра Linux 2.6.18 и 2.6.26, но более новые версии ядра не
портирован.

Предпосылки
В настоящее время NSC протестирован и работает на следующих платформах: Linux i386 и Linux.
х86-64. NSC не поддерживает powerpc. Использование во FreeBSD или OS X не поддерживается (хотя это
можно работать).

Для сборки NSC требуются пакеты flex и bison.

Настройка и Загрузка
Начиная с ns-3.17 или более поздней версии, NSC необходимо загружать отдельно из собственного репозитория,
или загрузки при использовании печь строить система of нс-3.

Для ns-3.17 или более поздних версий при использовании Bake необходимо настроить NSC как часть
конфигурация "allinone", например:

$ компакт-диск испечь
$ python Baker.py настроить -e ns-allinone-3.19
$ python Bake.py скачать
Сборка $ Python Bake.py

Вместо выпущенной версии можно использовать разрабатываемую версию ns-3, указав
«ns-3-allinone» на этапе настройки выше.

NSC также можно скачать с его скачать сайте используя Меркуриал:

Клон $ hg https://secure.wand.net.nz/mercurial/nsc

До выпуска ns-3.17 NSC был включен в tar-архив allinone, а выпущенный
версию не нужно было отдельно скачивать.

Здание и проверки
NSC может быть построен как часть процесса сборки; в качестве альтернативы можно построить НБК путем
сам использует свою систему сборки; например:

$ cd nsc-dev
$ питон scons.py

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

$ ./ваф настроить

Если ранее NSC был построен и найден waf, то вы увидите:

База сетевого моделирования: включена

Если NSC не найден, вы увидите:

Базовая станция сетевого моделирования: не включена (NSC не найден (см. Параметр --with-nsc))

В этом случае необходимо передать относительный или абсолютный путь к библиотекам NSC с параметром
Опция конфигурации "--with-nsc"; например

$ ./waf configure --with-nsc=/путь/к/моему/nsc/каталогу

Что касается нс-3 выпуски до выпуска ns-3.17, используя build.py скрипт в ns-3-allinone
каталог, NSC будет создан по умолчанию, если платформа не поддерживает его. К
явно отключите его при построении нс-3, тип:

$ ./waf настроить --enable-examples --enable-tests --disable-nsc

Если waf обнаружит NSC, то сборка нс-3 с NSC выполняется так же, как и с waf
без этого. Один раз нс-3 построен, попробуйте запустить следующий набор тестов:

$ ./test.py -s ns3-tcp-совместимость

Если НБК был успешно построен, в результатах должен появиться следующий тест:

PASS TestSuite ns3-tcp-совместимость

Это подтверждает, что NSC готов к использованию.

Применение
Есть несколько примеров файлов. Пытаться:

$ ./waf --запустить tcp-nsc-зоопарк
$ ./waf --запустите tcp-nsc-lfn

Эти примеры внесут некоторый вклад .pcap файлы в вашем каталоге, которые могут быть проверены с помощью
tcpdump или wireshark.

Посмотрим на примеры/tcp/tcp-nsc-zoo.cc файл для некоторого типичного использования. Как это
отличается от использования родного нс-3 ПТС? При использовании NSC имеется одна основная строка конфигурации.
и нс-3 вспомогательный API, который необходимо установить:

InternetStackHelper InternetStack;

internetStack.SetNscStack("liblinux2.6.26.so");
// это переключает узлы 0 и 1 на стек NSC Linux 2.6.26.
InternetStack.Install (п.Получить(0));
InternetStack.Install (п.Получить(1));

Ключевая линия – это SetNscStack. Это говорит помощнику InternetStack об объединении
экземпляры NSC TCP вместо собственного нс-3 TCP к остальным узлам. Это важно
чтобы эта функция вызывалась до вызывая Установить() функцию, как показано выше.

Какие стеки доступны для использования? В настоящее время основное внимание уделяется Linux 2.6.18 и Linux
2.6.26 стеки для нс-3. Чтобы увидеть, какие стеки были построены, можно выполнить следующую команду find
команда в нс-3 каталог верхнего уровня:

$ find nsc -имя "*.so" -тип f
нск/linux-2.6.18/liblinux2.6.18.so
нск/linux-2.6.26/liblinux2.6.26.so

Это говорит нам о том, что мы можем либо передать имя библиотеки liblinux2.6.18.so, либо
liblinux2.6.26.so на указанный выше шаг настройки.

Стек конфигурация
NSC TCP имеет те же атрибуты конфигурации, которые являются общими для сокетов TCP, как
описано выше и задокументировано в Доксиген

Кроме того, NSC TCP экспортирует множество переменных конфигурации в нс-3 Атрибуты
система, через Sysctl-подобный интерфейс. в примеры/tcp/tcp-nsc-зоопарк например, вы можете увидеть
следующая конфигурация:

// это отключает TCP SACK, wscale и временные метки на узле 1 (атрибуты
представляют sysctl-значения).
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_sack",
Строковое Значение ("0"));
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_timestamps",
Строковое Значение ("0"));
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_window_scaling",
Строковое Значение ("0"));

Эти дополнительные переменные конфигурации недоступны для собственного нс-3 ПТС.

Также обратите внимание, что значения по умолчанию для атрибутов TCP в нс-3 TCP может отличаться от nsc TCP
выполнение. В частности, в нс-3:

1. MSS TCP по умолчанию — 536.

2. Количество отложенных подтверждений TCP равно 2.

Поэтому при сравнении результатов, полученных с помощью nsc и нс-3 ПТС, уход
должны быть приняты для обеспечения того, чтобы эти значения были установлены надлежащим образом. Видеть
/examples/tcp/tcp-nsc-comparision.cc для примера.

NSC API
В этом подразделе описывается API, который NSC представляет для нс-3 или любой другой симулятор. НБК
предоставляет свой API в виде ряда классов, определенных в
сим/sim_interface.h в каталоге nsc.

· Инетстек INetStack содержит операции «низкого уровня» для сети операционной системы.
стек, например, функции ввода и вывода из и в сетевой стек (подумайте об этом как о
'интерфейс сетевого драйвера'. Есть также функции для создания новых сокетов TCP или UDP.

· ISendCallback Это вызывается NSC, когда пакет должен быть отправлен в сеть.
Этот симулятор должен использовать этот обратный вызов, чтобы повторно ввести пакет в симулятор, чтобы
фактические данные могут быть доставлены/направлены к месту назначения, где они в конечном итоге будут
передается в Receive() (и, в конечном итоге, обратно в экземпляр NSC получателя через
INetStack->if_receive() ).

· Инетстримсокет Это структура, определяющая конкретную конечную точку соединения (файл
дескриптор). Он содержит методы для работы с этой конечной точкой, например, подключение, отключение,
принять, прослушать, отправить_данные/прочитать_данные, ...

· IInterruptCallback Он содержит обратный вызов пробуждения, который вызывается NSC всякий раз, когда
происходит что-то интересное. Думайте о wakeup() как о замене операционной
функция пробуждения системы: Всякий раз, когда операционная система пробуждает процесс, который
ожидает завершения операции (например, рукопожатие TCP во время
connect()), NSC вызывает обратный вызов wakeup(), чтобы позволить симулятору проверить состояние
изменения в конечных точках соединения.

нс-3 реализация
Команда нс-3 реализация использует вышеуказанный API NSC и реализована следующим образом.

Три основные части:

· ns3:: NscTcpL4Протокол: подкласс Ipv4L4Protocol (и два класса nsc: ISendCallback
и IInterruptCallback)

· ns3:: NscTcpSocketImpl: подкласс TcpSocket

· ns3:: NscTcpSocketFactoryImpl: фабрика по производству новых розеток NSC

src/интернет/модель/nsc-tcp-l4-протокол является основным классом. При инициализации он загружает
сетевой стек nsc для использования (через dlopen()). Каждый экземпляр этого класса может использовать разные
куча. Используемый стек (=общая библиотека) задается с помощью метода SetNscLibrary() (на данный момент
время его вызывается косвенно через помощник интернет-стека). Затем настраивается стек nsc.
соответственно (таймеры и т.д.). Функция NscTcpL4Protocol::Receive() передает пакет
получает (должен быть полный пакет tcp/ip) в стек nsc для дальнейшей обработки. К
иметь возможность отправлять пакеты, этот класс реализует метод nsc send_callback. Этот метод
вызывается nsc всякий раз, когда стек nsc хочет отправить пакет в сеть. Его
аргументы — это необработанный буфер, содержащий полный пакет TCP/IP, и значение длины. Этот
поэтому метод должен преобразовать необработанные данные в Ptr может использоваться нс-3, Чтобы
во избежание различных проблем с заголовками ipv4, ip-заголовок nsc не включен. Вместо этого TCP
заголовок и фактическая полезная нагрузка помещаются в Ptr , после этого Пакет
передается на уровень 3 для отправки пакета (дальнейшая специальная обработка не требуется)
в пути кода отправки).

Этот класс вызывает ns3:: NscTcpSocketImpl как из обратного вызова nsc wakeup(), так и из
Путь получения (чтобы гарантировать, что данные, возможно, находящиеся в очереди, запланированы для отправки).

src/интернет/модель/nsc-tcp-сокет-импл реализует интерфейс сокетов nsc. Каждый экземпляр
имеет собственный nscTcpSocket. Данные, которые являются Send(), будут переданы в стек nsc через
m_nscTcpSocket->send_data(). (а не nsc-tcp-l4, это главное отличие по сравнению
в нс-3 ПТС). Класс также ставит в очередь данные, передаваемые методом Send(), перед базовым
дескриптор перешел в состояние ESTABLISHED. Этот класс вызывается из nsc-tcp-l4.
class, когда обратный вызов nsc-tcp-l4 wakeup() вызывается nsc. nsc-tcp-socket-impl затем
проверяет текущее состояние соединения (SYN_SENT, ESTABLISHED, LISTEN...) и планирует
соответствующие обратные вызовы по мере необходимости, например, сокет LISTEN запланирует Accept, чтобы увидеть, есть ли новый
соединение должно быть принято, сокет ESTABLISHED планирует любые ожидающие записи данные,
запланировать обратный вызов чтения и т. д.

Обратите внимание, что ns3:: NscTcpSocketImpl не взаимодействует с nsc-tcp напрямую: вместо этого данные
перенаправлены в нск. nsc-tcp вызывает nsc-tcp-sockets узла, когда его обратный вызов пробуждения
вызывается nsc.

ограничения
· NSC работает только на узлах с одним интерфейсом; попытка запустить его на мультиинтерфейсном узле
вызовет ошибку программы.

· Cygwin и OS X PPC не поддерживаются; OS X Intel не поддерживается, но может работать

· Не-Linux стеки NSC не поддерживаются в нс-3

· Поддерживаются не все обратные вызовы API сокетов.

Для получения дополнительной информации см. этой Вики страница.

КоДел очередь реализация in нс-3
В этой главе описывается реализация очереди CoDel ([Nic12], [Nic14]) в нс-3.

Разработано Кэтлин Николс и Ван Джейкобсон как решение проблемы буферного раздувания [Buf14].
проблема, CoDel (управление контролируемой задержкой) — это дисциплина управления очередями, которая использует
время пребывания (время в очереди) для принятия решения об отбрасывании пакетов.

Модель Описание
Исходный код модели CoDel находится в каталоге источник/интернет/модель и
состоит из 2 файлов код-queue.h и codel-queue.cc определение класса CoDelQueue и
вспомогательный класс CoDelTimestampTag. Код был перенесен на нс-3 Эндрю МакГрегора на основе
Код ядра Linux, реализованный Дэйвом Тахтом и Эриком Дюмазетом.

· класс CoDelQueue: Этот класс реализует основной алгоритм CoDel:

· КоДелкуеуэ:: Доэнкуеуэ (): Эта процедура помечает пакет текущим временем перед отправкой.
толкая его в очередь. Тег временной метки используется CoDelQueue::DoDequeue() в
вычислить время пребывания пакета. Если очередь заполнена при поступлении пакета, это
подпрограмма отбрасывает пакет и записывает количество отбрасываний из-за переполнения очереди,
который хранится в m_dropOverLimit.

· CoDelQueue::ShouldDrop (): Эта процедура CoDelQueue::DoDequeue()вспомогательная процедура
который определяет, следует ли отбрасывать пакет, в зависимости от времени его пребывания.
Если время пребывания превышает m_target и остается выше непрерывно, по крайней мере,
m_интервал, процедура возвращается правда указывающий, что можно отбросить пакет.
В противном случае возвращается ложный.

· CoDelQueue:: Додекуеуэ (): Эта процедура выполняет фактическое отбрасывание пакетов на основе
CoDelQueue::ShouldDrop ()возвращаемое значение и планирует следующее удаление.

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

Есть 2 филиала CoDelQueue:: Додекуеуэ ():

1. Если очередь в настоящее время находится в состоянии отбрасывания, что означает, что время пребывания
остался выше m_target для более чем m_интервал, подпрограмма определяет, можно ли
выйти из состояния сброса или пришло время для следующего сброса. Когда CoDelQueue::ShouldDrop ()
Возвращает ложный, очередь может выйти из состояния отбрасывания (установить м_дропинг в ложный).
В противном случае очередь постоянно отбрасывает пакеты и обновляет время следующего отбрасывания.
(m_dropСледующий) до тех пор, пока не будет выполнено одно из следующих условий:

1. Очередь пуста, после чего очередь выходит из состояния отбрасывания и закрывается.
CoDelQueue::ShouldDrop () рутина;

2. CoDelQueue::ShouldDrop () Возвращает ложный (это означает, что время пребывания ниже
m_target) после чего очередь выходит из состояния отбрасывания;

3. Еще не время для следующего дропа (m_dropСледующий меньше текущего времени) при
очередь ожидает следующего пакета, исключенного из очереди, чтобы снова проверить условие.

2. Если очередь не находится в состоянии отбрасывания, процедура переходит в состояние отбрасывания и
отбросить первый пакет, если CoDelQueue::ShouldDrop () Возвращает правда (имеется в виду пребывание
время прошло выше m_target как минимум m_интервал в первый раз или прошло
выше снова после того, как очередь выйдет из состояния отбрасывания).

Рекомендации
[Ник12]

К. Николс и В. Джейкобсон, Управление задержкой очереди, Очередь ACM, Vol. 10 № 5, май 2012 г.
Доступно онлайн на http://queue.acm.org/detail.cfm? id = 2209336.

[Ник14]

К. Николс и В. Джейкобсон, Internet-Draft: Controlled Delay Active Queue Management,
Март 2014 г. Доступно в Интернете по адресу
http://tools.ietf.org/html/draft-nichols-tsvwg-codel-02.

[Буф14]
Bufferbloat.net. Доступно онлайн по адресу http://www.bufferbloat.net/.

Атрибуты
Ключевые атрибуты, которые содержит класс CoDelQueue, включают следующее:

· Режим: Режим работы CoDel (BYTES, PACKETS или ILLEGAL). Режим по умолчанию — БАЙТЫ.

· Максимальное количество пакетов: Максимальное количество пакетов, которое может содержать очередь. Значение по умолчанию
DEFAULT_CODEL_LIMIT, то есть 1000 пакетов.

· Максимальное количество байтов: Максимальное количество байтов, которое может содержать очередь. Значение по умолчанию 1500 *
DEFAULT_CODEL_LIMIT, что составляет 1500 * 1000 байт.

· Мин. байт: Параметр minbytes алгоритма CoDel. Значение по умолчанию — 1500 байт.

· Интервал: Скользящее минимальное окно. Значение по умолчанию — 100 мс.

· Цель: Целевая задержка очереди алгоритма CoDel. Значение по умолчанию — 5 мс.

Примеры
Первый пример codel-vs-droptail-basic-test.cc находится в src/интернет/примеры. К
запустите файл (первый вызов ниже показывает доступные параметры командной строки):

$ ./waf --run "codel-vs-droptail-basic-test --PrintHelp"
$ ./waf --run "codel-vs-droptail-basic-test --queueType=CoDel --pcapFileName=codel.pcap --cwndTrFileName=cwndCodel.tr"

Ожидаемый результат предыдущих команд — два файла: codel.pcap файлов и
cwndCoDel.tr (файл трассировки ASCII) Файл .pcap можно проанализировать с помощью wireshark или
TCPTrace:

$ tcptrace -l -r -n -W codel.pcap

Второй пример codel-против-droptail-асимметричный.cc находится в src/интернет/примеры.
Этот пример предназначен для моделирования типичного сценария развертывания кабельного модема. Чтобы запустить
файл:

$ ./waf --run "codel-VS-Droptail-асимметричный --PrintHelp"
$ ./waf --run codel-vs-droptail-асимметричный

Ожидаемый результат предыдущих команд — шесть файлов pcap:

· кодель-против-дроптейл-асимметричный-CoDel-сервер-lan.pcap

· codel-vs-droptail-asymmetric-CoDel-router-wan.pcap

· codel-vs-droptail-asymmetric-CoDel-router-lan.pcap

· кодель-против-дроптейл-асимметричный-CoDel-cmts-wan.pcap

· кодель-против-дроптейл-асимметричный-CoDel-cmts-lan.pcap

· codel-vs-droptail-asymmetric-CoDel-host-lan.pcap

Один файл атрибутов:

· кодель-против-дроптейл-асимметричный-CoDel.attr

Пять файлов трассировки ASCII:

· кодель-против-дроптейл-асимметричный-CoDel-drop.tr

· codel-vs-droptail-asymmetric-CoDel-drop-state.tr

· codel-vs-droptail-asymmetric-CoDel-sojourn.tr

· codel-vs-droptail-asymmetric-CoDel-length.tr

· кодель-против-дроптейл-асимметричный-CoDel-cwnd.tr

Проверка
Модель CoDel тестируется с использованием Коделкуеуеуетестсюите класс, определенный в
src/интернет/тест/codel-queue-test-suite.cc. В комплект входит 5 тестовых случаев:

· Тест 1: Первый тест проверяет постановку/удаление из очереди без отбрасывания и убеждается, что
Атрибуты CoDel могут быть установлены правильно.

· Тест 2: Второй тест проверяет очередь с отбрасыванием из-за переполнения очереди.

· Тест 3: Третий тест проверяет арифметику NewtonStep() на соответствие явному порту Linux.
реализация

· Тест 4: Четвертый тест проверяет ControlLaw() на явный порт Linux.
реализация

· Тест 5: Пятый тест проверяет постановку/удаление из очереди с отбрасыванием согласно CoDel.
алгоритм

Набор тестов можно запустить с помощью следующих команд:

$ ./waf настроить --enable-examples --enable-tests
Сборка $ ./waf
$ ./test.py -s код-очередь

or

$ NS_LOG="CoDelQueue" ./waf --run "test-runner --suite=codel-queue"
Разрыв страницы

НИЗКАЯ СТАВКА WIRELESS ЛИЧНЫЙ ПЛОЩАДЬ СЕТЬ (LR-WPAN)

В этой главе описывается реализация моделей ns-3 для низкоскоростных беспроводных сетей.
персональная сеть (LR-WPAN) в соответствии со стандартом IEEE 802.15.4 (2006 г.).

Модель Описание
Исходный код модуля lr-wpan находится в каталоге src/lr-wpan.

Дизайн
Дизайн модели точно соответствует стандарту с архитектурной точки зрения.
[изображение] Архитектура и объем моделей lr-wpan.UNINDENT

Серые области на рисунке (адаптированном из рис. 3 стандарта IEEE 802.15.4-2006) показывают
размах модели.

Spectrum NetDevice от Никола Бальдо является основой для реализации.

В реализации также планируется позаимствовать модели ns-2, разработанные Чжэн и Ли.
в будущем.

API
API тесно следуют стандарту, адаптированному к соглашениям об именах и идиомам ns-3. То
API организованы вокруг концепции сервисных примитивов, как показано ниже.
рисунок адаптирован из рисунка 14 стандарта IEEE Std. 802.15.4-2006.
[изображение] Служебные примитивы.UNINDENT

API организованы вокруг четырех концептуальных служб и точек доступа к службам (SAP):

· Служба передачи данных MAC (MCPS)

· Служба управления MAC-адресами (MLME)

· Служба данных PHY (PD)

· Служба управления PHY (PLME)

Как правило, примитивы стандартизированы следующим образом (например, раздел 7.1.1.1.1 IEEE).
802.15.4-2006)::

MCPS-ДАННЫЕ.запрос (
SrcAddrMode,
ДстАдрРежим,
ДстПАНИд,
ДстАддр,
мсдуленгс,
мсду,
мсдуХандл,
ТхОпционс,
Уровень безопасности,
KeyIdMode,
источник ключей,
Ключевой индекс
)

Это соответствует классам и методам ns-3, таким как::

структура McpsDataRequestParameters
{
uint8_t m_srcAddrMode;
uint8_t m_dstAddrMode;
...
};

аннулировать
LrWpanMac::McpsDataRequest (параметры McpsDataRequestParameters)
{
...
}

MAC
MAC в настоящее время реализует вариант CSMA/CA без временных интервалов, без маяка. В настоящее время
нет поддержки координаторов и соответствующих API.

Реализованный MAC аналогичен NullMAC от Contiki, т. е. MAC без функций сна.
Предполагается, что радио всегда активно (принимает или передает) или полностью отключено.
вниз. Прием кадров не отключается при выполнении CCA.

Основным поддерживаемым API является API передачи данных (McpsDataRequest/Indication/Confirm).
Поддерживается CSMA/CA согласно Stc 802.15.4-2006, раздел 7.5.1.4. Прием кадров и
поддерживается отбраковка по Std 802.15.4-2006, раздел 7.5.6.2, в т.ч.
признания. Полностью реализована только короткая адресация. Различные источники трассировки
поддерживаются, а источники трассировки могут быть подключены к приемникам.

PHY
Компоненты физического уровня состоят из модели Phy, модели частоты ошибок и модели потерь.
модель. Модель частоты ошибок в настоящее время моделирует частоту ошибок для IEEE 802.15.4 2.4 ГГц.
канал AWGN для OQPSK; описание модели можно найти в IEEE Std 802.15.4-2006,
раздел Е.4.1.7. Модель Phy основана на SpectrumPhy и соответствует спецификации
описан в разделе 6 IEEE Std 802.15.4-2006. Он моделирует спецификации услуг PHY,
Форматы PPDU, константы PHY и атрибуты PIB. В настоящее время он поддерживает только передачу
маска спектральной плотности мощности, указанная в 2.4 ГГц согласно разделу 6.5.3.1. Мощность шума
плотность предполагает равномерное распределение теплового шума по полосам частот. Утрата
модель может полностью использовать все существующие простые (не спектральные) модели потерь. Модель Phy
использует существующую модель канала с одним спектром. Физический уровень моделируется пакетным
уровне, то есть определение преамбулы/SFD не выполняется. Прием пакетов начнется с
первый бит преамбулы (который не моделируется), если SNR больше -5 дБ, см.
IEEE Std 802.15.4-2006, приложение E, рисунок E.2. Прием пакета завершится после
пакет был полностью передан. Другие пакеты, поступающие во время приема, суммируются.
к помехам/шумам.

В настоящее время чувствительность приемника установлена ​​на фиксированное значение -106.58 дБмВт. Этот
соответствует частоте ошибок пакетов 1% для 20-байтовых эталонных пакетов для этого сигнала
мощность согласно IEEE Std 802.15.4-2006, раздел 6.1.7. В будущем мы предоставим
поддержка изменения чувствительности на разные значения.
[изображение] Коэффициент ошибочных пакетов в зависимости от мощности сигнала. UNINDENT

NetDevice
Хотя ожидается, что другие технологические профили (например, 6LoWPAN и ZigBee) будут
писать свои собственные классы NetDevice, предоставляется базовый LrWpanNetDevice, который инкапсулирует
общие операции по созданию универсального устройства LrWpan и соединению вещей вместе.

Объем и ограничения
Будущие версии этого документа будут содержать форму PICS, аналогичную Приложению D к
IEEE 802.15.4-2006. Текущий акцент делается на неслотовом режиме работы 802.15.4.
для использования в Zigbee, а возможности ограничены включением одного режима (CSMA/CA) с базовыми
возможности передачи данных. Ассоциация с координаторами PAN еще не поддерживается, и
использование расширенной адресации. Помехи моделируются как AWGN, но в настоящее время это не так.
тщательно протестировано.

Очередь NetDevice Tx не ограничена, т. е. пакеты никогда не отбрасываются из-за очереди.
становится полным. Они могут быть отброшены из-за чрезмерных попыток передачи или доступа к каналу.
отказ.

Рекомендации
· Спецификации управления доступом к беспроводной среде (MAC) и физического уровня (PHY) для
Низкоскоростные беспроводные персональные сети (WPAN), IEEE Computer Society, IEEE Std
802.15.4-2006, 8 сентября 2006 г.

·

Дж. Чжэн и Мён Дж. Ли, «Всестороннее исследование производительности IEEE 802.15.4», датчик
Сетевые операции, IEEE Press, Wiley Interscience, глава 4, стр. 218–237, 2006 г.

Применение
Включение lr-wpan
Добавить lr-wpan к списку модулей, построенных с помощью ns-3.

Помощник
Помощник создан по образцу других помощников устройств. В частности, трассировка (ascii и
pcap) включается аналогично, и выполняется включение всех компонентов лога lr-wpan
так же. Пример использования помощника показан на примеры/lr-wpan-data.cc. Для ascii
трассировка, трассировка передачи и приема подключается к уровню Mac.

Модель потерь при распространении по умолчанию, добавляемая в канал при использовании этого помощника, представляет собой
LogDistancePropagationLossModel с параметрами по умолчанию.

Примеры
Были написаны следующие примеры, которые можно найти в src/lr-wpan/примеры/:

· л-wpan-data.cc: Простой пример, показывающий сквозную передачу данных.

· lr-wpan-ошибка-расстояние-plot.cc: пример для построения вариаций успешности пакета.
отношение как функция расстояния.

· лр-wpan-ошибка-модель-plot.cc: Пример для проверки физ.

· lr-wpan-packet-print.cc: Пример распечатки полей заголовка MAC.

· л-wpan-phy-test.cc: Пример для проверки физ.

В частности, модуль обеспечивает очень упрощенный сквозной сценарий передачи данных,
в л-wpan-data.cc. На рисунке показана последовательность событий, которые срабатывают
когда MAC получает DataRequest от более высокого уровня. Он вызывает Чистый Канал
Оценка (CCA) с PHY, и в случае успеха отправляет кадр вниз на PHY, где он
передается по каналу и приводит к DataIndication на равноправном узле.
[изображение] Пример данных для простой сквозной передачи данных LR-WPAN. UNINDENT

Пример lr-wpan-ошибка-расстояние-plot.cc отображает коэффициент успешных пакетов (PSR) как
функция расстояния, используя модель потерь при распространении LogDistance по умолчанию и
Модель ошибки 802.15.4. Канал (по умолчанию 11), размер пакета (по умолчанию 20 байт) и
мощность передачи (по умолчанию 0 дБм) может быть изменена аргументами командной строки. Программа
выводит файл с именем 802.15.4-psr-distance.plt. Загрузка этого файла в gnuplot дает
файл 802.15.4-psr-distance.eps, который можно конвертировать в pdf или другие форматы. То
вывод по умолчанию показан ниже.
[изображение] Вывод программы по умолчанию lr-wpan-ошибка-расстояние-plot.cc.НЕИНДЕНТ

Tests
Были написаны следующие тесты, которые можно найти в src/lr-wpan/тесты/:

· lr-wpan-ack-test.cc: Убедитесь, что подтверждения используются и выдаются в
правильный заказ.

· lr-wpan-collision-test.cc: Проверить правильность приема пакетов с помехами и
столкновения.

· лр-wpan-ошибка-модель-test.cc: Убедитесь, что модель ошибок дает предсказуемые значения.

· lr-wpan-packet-test.cc: протестировать классы заголовков/концевых окон MAC 802.15.4.

· lr-wpan-pd-plme-sap-test.cc: протестируйте PLME и PD SAP в соответствии со стандартом IEEE 802.15.4.

· lr-wpan-спектр-значение-помощник-test.cc: Проверьте, что преобразование мощности
(выраженная скалярной величиной) и спектральная мощность, и обратно, попадает в пределы 25%
допуск в диапазоне возможных каналов и входных мощностей.

Проверка
Модель не проверялась на реальном оборудовании. Модель ошибки была
проверено по данным IEEE Std 802.15.4-2006, раздел E.4.1.7 (рисунок E.2). То
Поведение MAC (задержка CSMA) было проверено вручную на соответствие ожидаемому поведению. То
нижеприведенный график является примером проверки модели ошибки и может быть воспроизведен путем запуска
лр-wpan-ошибка-модель-plot.cc:
[изображение] Вывод программы по умолчанию лр-wpan-ошибка-модель-plot.cc.НЕИНДЕНТ

LTE МОДУЛЬ

Дизайн Документация
Обзор
Обзор имитационной модели LTE-EPC показан на рисунке. Обзор of
LTE-EPC моделирование модель. Есть два основных компонента:

· Модель LTE. Эта модель включает стек радиопротокола LTE (RRC, PDCP, RLC, MAC,
физ). Эти объекты полностью находятся в узлах UE и eNB.

· Модель EPC. Эти модели включают основные сетевые интерфейсы, протоколы и объекты.
Эти объекты и протоколы находятся в узлах SGW, PGW и MME и частично
в узлах eNB.
[изображение] Обзор модели моделирования LTE-EPC. UNINDENT

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

· Управление радиоресурсами

· Планирование пакетов с учетом QoS

· Координация межсотовых помех

· Динамический доступ к спектру

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

1. На радиоуровне степень детализации модели должна быть не ниже
Блок ресурсов (РБ). Фактически, это основная единица, используемая для ресурса.
распределение. Без этого минимального уровня детализации невозможно смоделировать
точное планирование пакетов и межсотовые помехи. Причина в том, что, поскольку
планирование пакетов выполняется для каждого RB, eNB может передавать только подмножество
всех доступных RB, следовательно, создавая помехи другим eNB только на тех RB, где
он передает. Обратите внимание, что это требование исключает принятие системы
подход моделирования уровня, который оценивает распределение ресурсов только на
степень детализации установления вызова/носителя.

2. Симулятор должен масштабироваться до десятков eNB и сотен пользовательских устройств (UE).
Это исключает использование имитатора уровня канала, т. е. имитатора, чья радиосвязь
Интерфейс моделируется с детализацией до уровня символа. Это потому, что
иметь модель уровня символов, необходимо реализовать все сигналы физического уровня
обработка, огромная вычислительная сложность которой сильно ограничивает моделирование. По факту,
имитаторы канального уровня обычно ограничены одним eNB и одним или несколькими UE.

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

4. Быть более представительным для стандарта LTE, а также быть как можно ближе
для реальных реализаций симулятор должен поддерживать API планировщика MAC
опубликовано Фемтофорумом [FFAPI]. Ожидается, что этот интерфейс будет использоваться
производителей фемтосот для реализации диспетчеризации и радиоресурсов
Алгоритмы управления (RRM). Внедрив поддержку этого интерфейса в
симулятор, мы даем возможность поставщикам и операторам LTE-оборудования протестировать
в симуляционной среде точно такие же алгоритмы, которые были бы развернуты в реальной
системы.

5. Имитационная модель LTE должна содержать собственную реализацию API, определенную в
[ФФАПИ]. Ни бинарная, ни структура данных несовместимы с конкретным поставщиком.
ожидаются реализации того же интерфейса; следовательно, слой совместимости
следует вставлять всякий раз, когда планировщик MAC-адресов конкретного поставщика должен использоваться с
симулятор. Это требование необходимо для обеспечения независимости тренажера.
из реализаций этой спецификации интерфейса, специфичных для конкретного поставщика. Мы отмечаем, что
[FFAPI] — это только логическая спецификация, и ее реализация (например, перевод
к какому-то конкретному языку программирования) остается на усмотрение поставщиков.

6. Модель должна использоваться для имитации передачи IP-пакетов высшим
слои. В связи с этим следует учитывать, что в LTE планирование и
Управление радиоресурсами работает не с IP-пакетами напрямую, а с RLC.
PDU, которые получаются путем сегментации и объединения IP-пакетов, выполняемых
объекты RLC. Следовательно, эти функциональные возможности уровня RLC должны быть смоделированы
точно.

EPC Модель
Основная цель модели EPC состоит в том, чтобы предоставить средства для моделирования сквозного
IP-подключение по модели LTE. С этой целью он поддерживает взаимосвязь
нескольких UE в Интернет через сеть радиодоступа из нескольких eNB, подключенных к
один узел SGW/PGW, как показано на рисунке Обзор of LTE-EPC моделирование модель.

Для модели EPC были выбраны следующие варианты конструкции:

1. Единственным поддерживаемым типом сети пакетной передачи данных (PDN) является IPv4.

2. Функциональные объекты SGW и PGW реализованы в рамках одного узла, т.е.
следовательно, называется узлом SGW/PGW.

3. Сценарии с мобильностью между SGW не представляют интереса. Следовательно, один SGW/PGW
node будет присутствовать во всех сценариях моделирования

4. Требование к модели EPC состоит в том, что ее можно использовать для имитации сквозного
производительность реалистичных приложений. Следовательно, должна быть возможность использовать с
EPC моделирует любое обычное приложение ns-3, работающее поверх TCP или UDP.

5. Еще одним требованием является возможность имитации сетевых топологий с
наличие нескольких eNB, некоторые из которых могут быть оснащены транзитным соединением
связь с ограниченными возможностями. Для имитации таких сценариев пользователь
протоколы плоскости данных, используемые между eNB и SGW/PGW, должны быть смоделированы
точно.

6. Должна быть возможность для одного UE использовать разные приложения с разными
Профили QoS. Следовательно, для каждого UE должно поддерживаться несколько каналов EPS. Этот
включает необходимую классификацию трафика TCP/UDP по IP, выполненную на UE в
восходящей линии связи и на PGW в нисходящей линии связи.

7. Основное внимание в модели EPC уделяется плоскости данных EPC. Точное моделирование
плоскость управления EPC пока не является обязательным требованием; следовательно
необходимые взаимодействия плоскости управления могут быть смоделированы упрощенным способом с помощью
используя прямое взаимодействие между различными объектами моделирования через
предоставлены вспомогательные объекты.

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

9. Модель должна позволять выполнять передачу обслуживания на основе X2 между двумя
eNB.

Архитектура
LTE Модель
UE архитектура
Архитектура модели стека радиопротокола LTE UE представлена ​​на
данные LTE радио протокол стек архитектура для UE on данным самолет и LTE радио
протокол стек архитектура для UE on контроль самолет которые выделяют соответственно
плоскость данных и плоскость управления.
[изображение] Архитектура стека радиопротокола LTE для UE на уровне данных. UNINDENT
[изображение] Архитектура стека радиопротокола LTE для UE на уровне управления. UNINDENT

Архитектура модели PHY/канала UE представлена ​​на рисунке. PHY и
канал модель архитектура для UE.
[изображение] PHY и архитектура модели канала для UE.UNINDENT

eNB архитектура
Архитектура модели стека радиопротокола LTE eNB представлена ​​на
данные LTE радио протокол стек архитектура для eNB on данным самолет и LTE радио
протокол стек архитектура для eNB on контроль самолет которые выделяют соответственно
плоскость данных и плоскость управления.
[изображение] Архитектура стека радиопротокола LTE для eNB на уровне данных. UNINDENT
[изображение] Архитектура стека протоколов радиосвязи LTE для eNB на уровне управления. UNINDENT

Архитектура модели PHY/канала eNB представлена ​​на рисунке. PHY и
канал модель архитектура для eNB.
[изображение] PHY и архитектура модели канала для eNB.UNINDENT

EPC Модель
EPC данным самолет
На рисунке LTE-EPC данным самолет протокол стек, мы представляем сквозные данные LTE-EPC
стек протоколов плоскости, как он моделируется в симуляторе. Из рисунка видно
что самым большим упрощением, внесенным в модель плоскости данных, является включение
Функции SGW и PGW в одном узле SGW/PGW, что устраняет необходимость в S5.
или интерфейсы S8, указанные 3GPP. С другой стороны, как для стека протоколов S1-U,
и в стеке радиопротокола LTE присутствуют все уровни протоколов, указанные 3GPP.
[изображение] Стек протоколов плоскости данных LTE-EPC. UNINDENT

EPC контроль самолет
Архитектура реализации модели плоскости управления показана на рисунке EPC
контроль модель. Интерфейсы управления, которые смоделированы явно, — это S1-AP, X2-AP
и интерфейсы S11.

Отметим, что интерфейсы S1-AP и S11 моделируются упрощенно, т.е.
используя только одну пару классов интерфейса для моделирования взаимодействия между сущностями, которые
находятся на разных узлах (eNB и MME для интерфейса S1-AP, а также MME и
SGW для интерфейса S11). На практике это означает, что примитивы этих
интерфейсы отображаются на прямой вызов функции между двумя объектами. С другой
С другой стороны, интерфейс X2-AP моделируется с использованием блоков данных протокола, отправляемых по каналу X2.
(смоделирован как точка-точка); по этой причине модель интерфейса X2-AP более
реалистично.
[изображение] Модель управления EPC. UNINDENT

Канал и Распространение
В целях моделирования каналов модуль LTE использует Спектрканал предоставленный интерфейс
по спектральному модулю. На момент написания этой статьи существовало две реализации такого интерфейса.
доступны: СинглМодельСпектрКанал и МультимодельСпектрКанали ЛТЕ
модуль требует использования МультимодельСпектрКанал для правильной работы. Этот
это связано с необходимостью поддержки различных конфигураций частоты и полосы пропускания. Все
модели распространения, поддерживаемые МультимодельСпектрКанал можно использовать в рамках
LTE-модуль.

Используйте of Здания модель LTE
Рекомендуемая модель распространения для использования с модулем LTE предоставлена
модуль Buildings, который на самом деле был разработан специально для LTE (хотя его можно
используется и с другими беспроводными технологиями). Пожалуйста, обратитесь к документации по
Модуль Buildings для получения общей информации о модели распространения, которую он предоставляет.

В этом разделе мы выделим некоторые соображения, которые особенно применимы, когда
Модуль зданий используется вместе с модулем LTE.

Соглашение об именах, используемое в дальнейшем, будет следующим:

· Пользовательское оборудование: UE

· Базовая станция макроса: MBS

· Базовая станция малых сот (например, пико/фемтосота): SC

Модуль LTE рассматривает только FDD и реализует распространение по нисходящей и восходящей линиям связи.
отдельно. Как следствие, выполняются следующие вычисления потерь на пути

· МБС <-> УП (внутри и снаружи)

· SC (внутри и снаружи) <-> UE (внутри и снаружи)

Модель LTE не обеспечивает следующие вычисления потерь на пути:

· УП <-> УП

· МБС <-> МБС

· МБС <-> СК

· СК <-> СК

Модель Buildings не знает фактического типа узла; то есть не в курсе
является ли передающий узел UE, MBS или SC. Скорее модель Buildings заботится только
о положении узла: закрытый он или открытый, и какова его ось z
относительно уровня крыши. Как следствие, для узла eNB, размещенного снаружи и
по координате z над уровнем крыши модели распространения, типичные для MBS, будут
используется модулем Buildings. И наоборот, для eNB, размещенного снаружи, но ниже
на крыше или в помещении будут использоваться модели распространения, типичные для пико- и фемтосот.

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

· МБС <-> внутреннее УП

· открытый SC <-> закрытый UE

· крытый СК <-> крытый УП

· внутренний SC <-> открытый UE

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

Замирание Модель
Модуль LTE включает в себя модель замирания на основе трассировки, полученную из модели, разработанной во время
GSoC 2010 [Piro2011]. Главной особенностью этой модели является то, что
оценка затухания во время выполнения моделирования основана на рассчитанных трассах. Это
сделано для ограничения вычислительной сложности симулятора. С другой стороны, нужно
огромные сооружения для хранения следов; следовательно, компромисс между количеством
возможные параметры и занятость памяти должны быть найдены. Наиболее важные из них:

· скорость пользователей: относительная скорость между пользователями (влияет на доплеровскую частоту, которая в
повороты влияет на свойство временной дисперсии замирания)

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

· временная гранулярность трассы: время выборки трассы.

· частотная гранулярность трассы: количество значений частоты, подлежащих оценке.

· длина трассы: идеально большая, как время симуляции, может быть уменьшена за счет работы с окнами
механизм.

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

Что касается математической модели распространения канала, мы предлагаем модель, представленную
Рэйличан функция Matlab, поскольку она обеспечивает хорошо принятый канал
моделирование как во временной, так и в частотной области. Для получения дополнительной информации читатель
упоминается [математика].

Симулятор предоставляет скрипт Matlab
(src/lte/model/fading-traces/fading-trace-generator.m) для создания трасс на основе
формат, используемый симулятором. Подробно, объект канала, созданный с помощью рейлейхана
Функция используется для фильтрации дискретного импульсного сигнала, чтобы получить
Импульсная характеристика канала. Фильтрация повторяется для разных TTI, что дает
последующие коррелированные по времени ответы канала (по одному на TTI). Затем ответ канала
обрабатывается с помощью пвелч функция для получения его значений спектральной плотности мощности, которая
затем сохраняются в файле с надлежащим форматом, совместимым с моделью симулятора.

Поскольку количество переменных довольно велико, сгенерируйте трассировки, учитывая их все.
может создавать большое количество следов огромного размера. По этому вопросу мы рассмотрели
следующие предположения о параметрах, основанные на условиях распространения замираний 3GPP
(см. Приложение B.2 к [TS36104]):

· скорость пользователей: обычно учитываются только несколько дискретных значений, т.е.:

· 0 и 3 км/ч для пешеходных сценариев

· 30 и 60 км/ч для автомобильных сценариев

· 0, 3, 30 и 60 для городских сценариев

· отводы каналов: обычно рассматривается только ограниченное количество наборов отводов каналов,
например, три модели упомянуты в Приложении B.2 к [TS36104].

· гранулярность по времени: нам нужно одно значение затухания на TTI, т. е. каждую 1 мс (поскольку это
гранулярность во времени модели ns-3 LTE PHY).

· гранулярность частоты: нам нужно одно значение замирания на RB (которое является частотой
степень детализации модели спектра, используемой моделью ns-3 LTE).

· длина трассы: в симуляторе реализован оконный механизм
во время GSoC 2011, который состоит из выбора окна трассировки каждого окна
длина случайным образом.

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

В соответствии с рассмотренными нами параметрами следующая формула подробно выражает
общий размер S_{traces} трасс затухания:

где S_{выборка} — размер выборки в байтах (например, 8 в случае двойной точности,
4 в случае точности с плавающей запятой), N_{RB} — количество рассматриваемых RB или набор RB,
T_{trace} — общая длина трассы, T_{sample} — временное разрешение трассы.
(1 мс), а N_{scenarios} — количество желаемых сценариев замирания (т. е.
комбинации различных наборов нажатий каналов и значений скорости пользователя). Мы предоставляем следы
для 3 различных сценариев, по одному для каждой конфигурации отводов, определенной в Приложении B.2
[ТС36104]:

· Пешеходный: со скоростью узлов 3 км/ч.

· Автомобиль: со скоростью узлов 60 км/ч.

· Городской: со скоростью узлов 3 км/ч.

следовательно, N_{scenarios} = 3. Все трассы имеют T_{trace} = 10 с и RB_{NUM} = 100. Это приводит к
в общей сложности 24 МБ байтов трассировки.

Антенны
Основываясь на СпектрФизический, модель LTE PHY поддерживает моделирование антенны через ns-3
АнтеннаМодель класс. Следовательно, любая модель, основанная на этом классе, может быть связана с любым eNB или
экземпляр УЭ. Например, использование КосинусАнтеннаМодель связанный с устройством eNB
позволяет моделировать один сектор макро базовой станции. По умолчанию ИзотропнаяАнтеннаМодель
используется как для eNB, так и для UE.

PHY
Обзор
Модель физического уровня, представленная в этом симуляторе LTE, основана на модели, описанной в
[Piro2011], со следующими изменениями. Модель теперь включает в себя межячейку
расчет интерференции и моделирование восходящего трафика, включая пакетный
передача и генерация CQI.

подкадр Структура:
Подкадр разделен на часть управления и часть данных, как показано на рисунке. LTE подкадр
деление..
[изображение] Разделение подкадра LTE.. UNINDENT

Учитывая гранулярность симулятора на основе РБ, контрольной и эталонной
Следовательно, сигнализация должна быть смоделирована с учетом этого ограничения. Согласно
стандарт [TS36211], кадр управления нисходящей линии связи начинается в начале каждого подкадра
и длится до трех символов по всей полосе пропускания системы, где фактический
продолжительность обеспечивается каналом индикатора формата физического управления (PCFICH).
информация о выделении затем отображается в оставшийся ресурс до
продолжительность, определяемая PCFICH, в так называемом физическом канале управления нисходящей линии связи
(ПДКЧ). PDCCH передает одно сообщение, называемое управляющей информацией нисходящей линии связи (DCI).
поступающие с уровня MAC, где планировщик указывает выделение ресурсов для
конкретного пользователя. PCFICH и PDCCH моделируются с передачей управления
кадр фиксированной продолжительности 3/14 миллисекунды, охватывающий весь доступный
пропускная способность, так как планировщик не оценивает размер области управления. Этот
подразумевает, что один блок передачи моделирует весь кадр управления с фиксированным
мощность (т. е. мощность, используемая для PDSCH) по всем доступным RB. Согласно этому
функция, эта передача представляет собой также ценную поддержку опорного сигнала
(РС). Это позволяет иметь для каждого TTI оценку сценария помех, поскольку
все eNB передают (одновременно) кадр управления по соответствующему
доступные полосы пропускания. Отметим, что модель не включает форсирование мощности, т.к.
это не отражает каких-либо улучшений в реализованной модели оценки канала.

Зондирующий опорный сигнал (SRS) моделируется аналогично кадру управления нисходящей линии связи.
SRS периодически помещается в последний символ подкадра во всей системе.
пропускная способность. Модуль RRC уже включает алгоритм динамического назначения
периодичность как функция фактического количества UE, подключенных к eNB, в соответствии с
Процедура, специфичная для UE (см. раздел 8.2 [TS36213]).

MAC в Канал задерживать
Чтобы смоделировать задержку реальных реализаций MAC и PHY, модель PHY имитирует
Задержка между MAC и каналом, кратная TTI (1 мс). Передача как данных, так и управления
пакеты задерживаются на эту величину.

ИКК Обратная связь
Генерация обратной связи CQI выполняется в соответствии с тем, что указано в [FFAPI]. В
подробно, мы рассмотрели генерацию периодического широкополосного CQI (т. е. одно значение
состояние канала, которое считается репрезентативным для всех используемых RB) и внутриполосных CQI (т. е.
набор значений, представляющих состояние канала для каждого RB).

Сообщаемый индекс CQI получается путем получения сначала измерения SINR, а затем
передавая это измерение SINR адаптивной модуляции и кодированию, которое сопоставит его с
Индекс CQI.

В нисходящей линии связи SINR, используемый для генерации обратной связи CQI, может быть рассчитан двумя разными способами.
способы:

1. Ctrl метод: SINR вычисляется путем объединения мощности сигнала из эталонного
сигналы (которые в моделировании эквивалентны PDCCH) и помехи
питание от PDCCH. Этот подход приводит к тому, что любой соседний eNB рассматривается как
источник помех, независимо от того, действительно ли этот eNB выполняет какой-либо PDSCH
передачи, и независимо от мощности и RB, используемых для возможных помех
передачи PDSCH.

2. смешанный метод: SINR вычисляется путем объединения мощности сигнала из эталонного
сигналы (которые в моделировании эквивалентны PDCCH) и помехи
питание от PDSCH. Этот подход приводит к тому, что в качестве источников помех рассматриваются только те
соседние eNB, которые активно передают данные по PDSCH, и позволяет
генерировать внутриполосные CQI, которые учитывают различное количество помех на разных
RB в соответствии с фактическим уровнем помех. В случае отсутствия PDSCH
передача выполняется любым eNB, этот метод считает, что помехи
ноль, т. е. SINR будет рассчитываться только как отношение сигнала к шуму.

Чтобы переключиться между этими двумя подходами генерации CQI, LteHelper::UsePdschForCqiGeneration
необходимо настроить: false для первого подхода и true для второго подхода (true
значение по умолчанию):

Config::SetDefault("ns3::LteHelper::UsePdschForCqiGeneration", BooleanValue (true));

В восходящем канале реализованы два типа CQI:

· Основанный на SRS, периодически отправляемый UE.

· Основанный на PUSCH, рассчитанный на основе фактически переданных данных.

Интерфейс планировщика включает систему атрибутов, называемую UlCqiФильтр для управления
фильтрация CQI в соответствии с их характером, в деталях:

· SRS_UL_CQI для хранения только CQI на основе SRS.

· PUSCH_UL_CQI для хранения только CQI на основе PUSCH.

· ALL_UL_CQI для хранения всех полученных CQI.

Необходимо отметить, что, ФфМакШадулер предоставляет только интерфейс и это вопрос
фактической реализации планировщика, чтобы включить код для управления этими атрибутами
(см. раздел, связанный с планировщиком, для получения дополнительной информации по этому вопросу).

Вмешательство Модель
Модель PHY основана на известных интерференционных моделях Гаусса, согласно которым
мощности мешающих сигналов (в линейных единицах) суммируются для определения
общая мощность помех.

Диаграмма последовательности на рисунке Последовательность диаграмма of PHY вмешательство расчет
процедуры показывает, как мешающие сигналы обрабатываются для расчета SINR, и как SINR
затем используется для генерации обратной связи CQI.
[изображение] Диаграмма последовательности процедуры расчета помех PHY. UNINDENT

LTE Спектр Модель
Использование радиоспектра узлами eNB и UE в LTE описано в [TS36101]. в
симулятор, использование радиочастотного спектра моделируется следующим образом. Пусть f_c обозначает LTE Absolute
Номер радиочастотного канала, который определяет несущую частоту на частоте 100 кГц.
растр; кроме того, пусть B будет Конфигурацией полосы пропускания передачи в количестве
Блоки ресурсов. Для каждой пары (f_c,B), используемой в моделировании, мы определяем соответствующий
SpectrumModel, используя функциональность модуля sec-spectrum-module. модель с использованием
Фреймворк Spectrum описан в [Baldo2009]. f_c и B можно настроить для каждого
eNB, созданный при моделировании; следовательно, каждый eNB может использовать другую модель спектра.
Каждое UE будет автоматически использовать модель спектра eNB, к которому оно подключено. Используя
MultiModelSpectrumChannel, описанный в [Baldo2009], помехи между eNB, которые используют
должным образом учитываются различные модели спектра. Это позволяет моделировать динамические
политики доступа к спектру, такие как, например, политика лицензирования спектра,
обсуждалось в [Ofcom2600MHz].

Данные PHY Ошибка Модель
Симулятор включает в себя модель ошибок плоскости данных (т. е. PDSCH и PUSCH) в соответствии с
к стандартным методам сопоставления связи с системой (LSM). Выбор согласуется с
стандартная методология системного моделирования технологии радиопередачи OFDMA. Благодаря
LSM мы можем поддерживать хороший уровень точности и в то же время ограничивать
увеличение вычислительной сложности. Он основан на сопоставлении одноканального уровня.
производительность, полученная с помощью симуляторов уровня связи с системой (в нашем случае сетью)
тренажеры. В частности, симулятор слоя используется для создания производительности.
одной ссылки с точки зрения физического уровня, обычно с точки зрения частоты ошибок блока кода
(BLER) в определенных статических условиях. LSM позволяет использовать эти параметры в более
сложные сценарии, типичные для системных/сетевых симуляторов, где у нас больше ссылок,
явления интерференции и «цветного» распространения каналов (например, частотно-избирательные
затухание).

Для этого был использован симулятор Vienna LTE [ViennaLteSim].
извлечение производительности канального уровня и эффективного SINR на основе взаимной информации
(MIESM) в качестве функции отображения LSM с использованием части работы, недавно опубликованной Signet.
Группа Университета Падуи [PaduaPEM].

МИЕСМ
Конкретный принятый метод LSM основан на использовании взаимной информации.
метрика, обычно называемая взаимной информацией на кодированный бит (MIB или MMIB, когда
задействовано среднее значение нескольких MIB). Другой вариант будет представлен
Экспоненциальная ЭСМ (ЭСМ); однако недавние исследования показывают, что MIESM превосходит EESM в
с точки зрения точности [LozanoCost].
[изображение] Схема вычислительной процедуры MIESM. UNINDENT

Взаимная информация (MI) зависит от отображения созвездия и может быть
рассчитывается на основе транспортного блока (ТБ) путем оценки MI по символам и
поднесущая. Однако это было бы слишком сложно для симулятора сети. Следовательно, в нашем
рассмотрена реализация плоского отклика канала в пределах RB; Следовательно
общий MI TB рассчитывается путем усреднения MI, оцененного для каждого RB, используемого в TB.
Подробно реализованная схема изображена на рис. МИЕСМ вычислительный процедуры
диаграмма, где мы видим, что модель начинается с оценки значения MI для каждого RB,
представлены на рисунке выборками SINR. Затем эквивалентный МИ оценивается на
на основе TB путем усреднения значений MI. Наконец, необходимо сделать еще один шаг, поскольку
Симулятор уровня канала возвращает производительность канала с точки зрения частоты блочных ошибок.
(BLER) в канале с аддитивным белым гуассовым шумом (AWGN), где блоки представляют собой код
блоков (CB), независимо кодируемых/декодируемых турбокодером. По этому вопросу
стандартная схема сегментации 3GPP использовалась для оценки фактического размера CB
(описано в разделе 5.1.2 [TS36212]). Эта схема делит ТБ на N_{K_-}
блоков размера K_- и N_{K+} блоков размера K_+. Таким образом, общий TB BLER (TBLER)
может быть выражено как

где CBLER_i — это BLER CB i, полученный в соответствии с симулятором уровня канала.
Кривые CB BLER. Для оценки CBLER_i была реализована оценка MI.
согласно его числовой аппроксимации, определенной в [wimaxEmd]. Более того, для уменьшения
сложность вычислений, аппроксимация была преобразована в поиск
столы. В частности, кумулятивная модель Гаусса использовалась для аппроксимации AWGN.
Кривые BLER с тремя параметрами, которые обеспечивают близкое соответствие стандартному AWGN.
выступления, по формуле:

где x - это MI TB, b_{ECR} представляет собой «переходный центр», а c_{ECR} представляет собой
связанный с «шириной перехода» гауссовского кумулятивного распределения для каждого
Эффективная кодовая скорость (ECR), которая представляет собой фактическую скорость передачи в соответствии с каналом.
кодирование и МКС. Для ограничения вычислительной сложности модели мы рассмотрели
только подмножество возможных ECR, на самом деле у нас потенциально 5076 возможных ECR.
(т.е. 27 MCS и 188 размеров CB). В связи с этим мы ограничим размеры CB некоторыми
репрезентативные значения (т.е. 40, 140, 160, 256, 512, 1024, 2048, 4032, 6144), а для
для остальных будет использоваться наихудший, приближенный к реальному (т. е. меньший CB
доступное значение размера относительно реального). Этот выбор соответствует типичному
производительность турбокодов, где размер CB не сильно влияет на BLER.
Однако следует отметить, что для размеров CB менее 1000 бит эффект может быть
релевантные (т.е. до 2 дБ); поэтому мы принимаем этот несбалансированный интервал выборки для
с большей точностью там, где это необходимо. Такое поведение подтверждается цифрами
представлены в разделе Annes.

БЛЕР Кривые
В связи с этим мы повторно использовали часть кривых, полученных в [PaduaPEM]. Подробно мы
введена зависимость размера CB от кривых BLER CB при поддержке разработчиков
[PaduaPEM] и LTE Vienna Simulator. Фактически, выпущенный модуль обеспечивает
производительность канального уровня только для того, что касается MCS (т. е. с заданным фиксированным ECR). В
детализировать новые кривые коэффициента ошибок для каждого из них были оценены с помощью кампании по моделированию
с симулятором канального уровня для одиночного канала с шумом AWGN и размером CB 104,
140, 256, 512, 1024, 2048, 4032 и 6144. Эти кривые были нанесены на карту с помощью гауссовой
кумулятивная модельная формула, представленная выше, для получения соответствий b_{ECR} и
параметры c_{ECR}.

Показатели BLER всех MCS, полученные с помощью симулятора уровня канала, представлены на графике.
следующие цифры (синие линии) вместе с их соответствующим отображением на гауссову
кумулятивное распределение (красные пунктирные линии).
[изображение] BLER для MCS 1, 2, 3 и 4.. UNINDENT
[изображение] BLER для MCS 5, 6, 7 и 8.. UNINDENT
[изображение] BLER для MCS 9, 10, 11 и 12.. UNINDENT
[изображение] BLER для MCS 13, 14, 15 и 16.. UNINDENT
[изображение] BLER для MCS 17, 17, 19 и 20.. UNINDENT
[изображение] BLER для MCS 21, 22, 23 и 24.. UNINDENT
[изображение] BLER для MCS 25, 26, 27 и 28.. UNINDENT
[изображение] BLER для MCS 29..UNINDENT

интеграцию of БЛЕР Кривые in нс-3 LTE модуль
Реализованная модель использует кривые для LSM недавно разработанной LTE PHY Error Model.
выпущены в сообществе ns3 группой Signet [PaduaPEM] и созданы новые
для разных размеров ЦБ. LteSpectrumPhy класс отвечает за оценку TB BLER
благодаря методам, предложенным Лтемиеррормодел класс, который отвечает за
оценка TB BLER в соответствии с вектором воспринимаемого SINR на RB, MCS и
размер, чтобы правильно смоделировать сегментацию ТБ в CB. Чтобы получить
вектор воспринимаемого SINR два экземпляра LtePemSinrChunkProcessor (ребенок
LteChunkПроцессор предназначен для оценки SINR для получения характеристик физических ошибок)
были подключены к нисходящей линии связи UE и восходящей линии связи eNB LteSpectrumPhy модули для оценки
распределение модели ошибок соответственно PDSCH (сторона UE) и ULSCH (сторона eNB).

Модель можно отключить для работы с каналом с нулевыми потерями, установив параметр Пемэнаблед
атрибут LteSpectrumPhy класс (по умолчанию активен). Это можно сделать согласно
к стандартной процедуре системы атрибутов ns3, а именно:

Config::SetDefault("ns3::LteSpectrumPhy::DataErrorModelEnabled", BooleanValue (false));

Контролировать Каналы PHY Ошибка Модель
Симулятор включает в себя модель ошибок для каналов управления нисходящей линии связи (PCFICH и PDCCH),
в то время как в восходящем канале предполагается и идеальный безошибочный канал. Модель основана на
Представленный ранее подход MIESM для рассмотрения эффектов частотно-избирательного
канала, так как большинство каналов управления охватывают всю доступную полосу пропускания.

ПКФИЧ + ПДКЧ Ошибка Модель
Модель, принятая для распределения ошибок этих каналов, основана на оценке
исследование, проведенное в RAN4 3GPP, где разные поставщики исследовали
производительность демодуляции PCFICH совместно с PDCCH. Это связано с тем, что
PCFICH — это канал, отвечающий за передачу UE фактических размеров
PDCCH (который охватывает от 1 до 3 символов); Поэтому правильная расшифровка
DCI зависит от правильной интерпретации обоих. В 3GPP эта проблема есть
была оценена для улучшения производительности границы ячейки [FujitsuWhitePaper], где
интерференция между соседними сотами может быть относительно высокой из-за ухудшения сигнала. А
аналогичная проблема была замечена в сценарии фемтосоты и, в целом, в HetNet.
сценариев узкое место было обнаружено главным образом как канал PCFICH [Bharucha2011],
где в случае развертывания множества eNB в одной и той же зоне обслуживания этот канал может конфликтовать
по частоте, что также делает невозможным правильное обнаружение канала PDCCH.

В симуляторе SINR, воспринимаемый во время приема, оценивался в соответствии с
модель MIESM, представленную выше, чтобы оценить распределение ошибок PCFICH и
ПДКЧ. В частности, выборки SINR всех RB включены в оценку MI.
связанный с кадром управления и, в соответствии с этими значениями, эффективный SINR (eSINR)
получается путем инвертирования процесса оценки MI. Необходимо отметить, что в случае
При передаче MIMO как PCFICH, так и PDCCH всегда используют режим разнесения при передаче, поскольку
определяется стандартом. По eSINR воспринимается ошибка декодирования
вероятность может быть оценена как функция результатов, представленных в [R4-081920]. В случае
происходит ошибка, DCI отбрасываются, и, следовательно, UE не сможет принимать
корреспондент Tbs, поэтому в результате утерян.

MIMO Модель
Использование нескольких антенн как на стороне передатчика, так и на стороне приемника, известное как
множественный вход и множественный выход (MIMO) — проблема, хорошо изученная в литературе во время
прошлые годы. Большая часть работы сосредоточена на аналитической оценке выигрыша, который
разные схемы MIMO могут иметь пропускную способность; однако кто-то также предоставляет
информация о выигрыше с точки зрения полученной мощности [CatreuxMIMO].

Согласно изложенным выше соображениям, более гибкая модель может быть получена с учетом
выигрыш, который схемы MIMO приносят в систему со статистической точки зрения. В виде
выделенный ранее, [CatreuxMIMO] представляет статистическую выгоду нескольких решений MIMO.
относительно SISO в случае отсутствия корреляции между антеннами. В работе
усиление представлено как кумулятивная функция распределения (CDF) выходного SINR для
что касается схем SISO, MIMO-Alamouti, MIMO-MMSE, MIMO-OSIC-MMSE и MIMO-ZF.
Обрабатывая результаты, выходное распределение SINR можно аппроксимировать с помощью
логнормальный с различными средним значением и дисперсией в зависимости от рассматриваемой схемы.
Однако дисперсии не так уж различаются и примерно равны дисперсии
режима SISO, уже включенного в компонент теневого копирования
ЗданияРаспространениеПотериМодель, в деталях:

· SISO: = 13.5 и ma = 20 [дБ].

· MIMO-Alamouti: = 17.7 и ma = 11.1 [дБ].

· MIMO-MMSE: = 10.7 и ma = 16.6 [дБ].

· MIMO-OSIC-MMSE: = 12.6 и ma = 15.5 [дБ].

· MIMO-ZF: = 10.3 и ma = 12.6 [дБ].

Следовательно, уровень PHY реализует модель MIMO как усиление, воспринимаемое приемником.
при использовании схемы MIMO относительно схемы, полученной с использованием схемы SISO. Отметим, что эти
усиление относится к случаю, когда нет корреляции между антеннами в MIMO
схема; поэтому не моделируйте деградацию из-за корреляции путей.

UE PHY измерения Модель
Согласно [TS36214], UE должно сообщать о наборе измерений eNB, которые
устройство способно воспринимать: мощность принимаемого опорного сигнала (RSRP) и
качество принятого опорного сигнала (RSRQ). Первый является мерой полученной мощности
конкретного eNB, в то время как последний включает также помехи канала и тепловой шум.
UE должно сообщать об измерениях вместе с идентификатором физической соты (PCI) устройства.
клетка. Во время приема RS выполняются измерения как RSRP, так и RSRQ.
в то время как PCI получается с помощью первичного сигнала синхронизации (PSS). PSS отправлен
eNB каждые 5 подкадров и подробно в подкадрах 1 и 6. В реальных системах только
Доступно 504 отдельных PCI, и, следовательно, может случиться так, что два соседних eNB используют
тот же PCI; однако в симуляторе мы моделируем PCI, используя метаданные моделирования, и мы разрешаем
до 65535 отдельных PCI, тем самым избегая коллизий PCI при условии, что менее 65535
eNB моделируются по тому же сценарию.

Согласно [TS36133], разделы 9.1.4 и 9.1.7, RSRP сообщается физическим уровнем в дБм.
в то время как RSRQ в дБ. Значения RSRP и RSRQ передаются на более высокие уровни через
C-PHY SAP (посредством UeИзмеренияПараметры struct) каждые 200 мс, как определено в
[TS36331]. Фильтрация уровня 1 выполняется путем усреднения всех собранных измерений.
во время последнего слота окна. Периодичность отчетности может быть скорректирована для исследования
целях с помощью LteUePhy::UeMeasurementsFilterPeriod атрибутов.

Формулы RSRP и RSRQ можно упростить, учитывая допущение PHY
уровень, что канал плоский в пределах RB, самый высокий уровень точности. На самом деле это
подразумевает, что все RE внутри RB имеют одинаковую мощность, поэтому:

где P(k,m) представляет собой мощность сигнала RE m в пределах RB k, которая, как
до, постоянна в пределах одного и того же РБ и равна P(k), M – количество RE, несущих
RS в RB, а K - количество RB. Следует отметить, что P(k) и вообще все
полномочия, определенные в данном разделе, получаются в тренажере из СДП РБ
(что обеспечивается Процессор LteInterferencePowerChunk), в деталях:

где PSD_{RB}(k) — спектральная плотность мощности RB k, 180000 — ширина полосы в Гц.
RB, а 12 — количество RE на RB в символе OFDM. Аналогично, для RSSI мы
встали на сторону

где S — количество символов OFDM, несущих RS в RB, а R — количество RE.
несущий RS в символе OFDM (который фиксируется на 2), в то время как P (k, s, r), I (k, s, r) и N (k, s, r)
представляют соответственно воспринимаемую мощность обслуживающей соты, мощность помех и
мощность шума RE r в символе s. Что касается RSRP, измерения внутри RB
всегда равны между собой по модели PHY; поэтому P(k,s,r) = P(k),
I(k,s,r) = I(k) и N(k,s,r) = N(k), что означает, что RSSI можно рассчитать как:

Принимая во внимание ограничения реализации цепочки приема PHY и для того, чтобы
поддерживать низкий уровень вычислительной сложности, напрямую можно получить только RSRP для
все клетки. Это связано с тем, что LteSpectrumPhy предназначен для оценки
помехи только в отношении сигнала обслуживающего eNB. Это означает, что PHY
уровень оптимизирован для управления информацией о сигналах мощности с обслуживающим eNB в качестве
Справка. Однако RSRP и RSRQ соседней ячейки i могут быть извлечены текущим
доступная информация об обслуживающей соте j, как подробно описано ниже:

где RSRP_i — RSRP соседней соты i, P_i(k) — мощность, воспринимаемая на любом RE
в RB k, K — общее количество RB, RSSI_i — RSSI соседней соты i
когда UE подключено к ячейке j (которая, поскольку это сумма всех полученных мощностей,
совпадает с RSSI_j), I_j(k) — суммарная помеха, воспринимаемая UE в любом RE RB k
при присоединении к ячейке i (полученной Процессор LteInterferencePowerChunk), P_j(k) есть
мощность, воспринимаемая сотой j в любом РЭ РБ k, а N – спектральная мощность шума
плотность в любом RE. Образец считается действительным, если оцениваемый RSRQ
выше LteUePhy:: RsrqUeMeasThreshold атрибутов.

ГАЗП
Реализованная схема HARQ основана на объединении решений с инкрементной избыточностью (IR).
с несколькими процессами остановки и ожидания для обеспечения непрерывного потока данных. Подробно,
принятое решение является легонько комбинируя гибрид IR Длинный дополнительный избыточность (также называемый
IR Type II), который подразумевает, что повторные передачи содержат только новую информацию относительно
к предыдущим. Реализован алгоритм распределения ресурсов HARQ.
внутри соответствующих классов планировщика (т.е. РрФфМакПланировщик и ПфФфМакПланировщик,
обратитесь к соответствующим разделам для получения дополнительной информации), в то время как часть декодирования
HARQ был реализован в LteSpectrumPhy и LteHarqPhy занятия, которые будут
подробно в этом разделе.

В соответствии со стандартом повторные передачи UL являются синхронными и, следовательно,
выделяется через 7 мс после исходной передачи. С другой стороны, для DL они
асинхронный и поэтому может распределяться более гибко, начиная с 7 мс и
это вопрос конкретной реализации планировщика. Поведение процессов HARQ
изображен на рисунке: ссылка:fig-harq-процессы-схема.

На уровне MAC объект HARQ, находящийся в планировщике, отвечает за управление
8 процессов HARQ для генерации новых пакетов и управления повторными передачами как для
DL и UL. Планировщик собирает обратную связь HARQ от физического уровня eNB и UE.
(соответственно для UL и DL соединения) с помощью примитивов FF API
СчедУлтриггеррек и СчедУлтриггеррек. Согласно отзывам HARQ и RLC
буферов, планировщик генерирует набор DCI, включая обе повторные передачи
Блоки HARQ, получившие ошибочные и новые передачи, как правило, отдавали приоритет
бывший. В этом отношении планировщик должен учитывать одно ограничение, когда
выделяя ресурс для повторных передач HARQ, он должен использовать тот же порядок модуляции, что и
первая попытка передачи (т.е. QPSK для MCS в [0..9], 16QAM для MCS в [10..16]
и 64QAM для MCS в [17..28]). Это ограничение исходит из спецификации скорости
сопоставитель в стандарте 3GPP [TS36212], где алгоритм фиксирует порядок модуляции для
генерация различных блоков версий резервирования.

Модель модели ошибок PHY (т. е. Лтемиеррормодел класс, уже представленный ранее) имеет
был расширен для рассмотрения IR HARQ в соответствии с [wimaxEmd], где параметры для
отображение кривых AWGN для отображения MIESM в случае повторных передач определяется следующим образом:

где X — количество исходных информационных битов, C_i — количество закодированных битов, M_i —
взаимная информация на блок HARQ, полученная при общем числе q повторных передач.
Поэтому, чтобы иметь возможность вернуть вероятность ошибки с моделью ошибки
реализованный в симуляторе, оценивает R_{eff} и MI_{I eff} и возвращает значение
вероятности ошибки ECR той же модуляции с ближайшей более низкой скоростью по отношению к
R_ {эфф}. Чтобы учесть влияние повторных передач HARQ, новый набор кривых
были интегрированы по сравнению со стандартным, используемым для оригинальной MCS. Новые кривые
предназначены для покрытия случаев, когда используется наиболее консервативная МКС модуляции
что подразумевает генерацию R_{eff} ниже, чем у стандартных MCS. На этом
кривые для 1, 2 и 3 ретрансляций были оценены для 10 и 17. Для
MCS 0 мы учитывали только первую повторную передачу, поскольку производимая кодовая скорость уже
очень консервативен (т. е. 0.04) и возвращает частоту ошибок, достаточную для приема
(т. е. спад BLER сосредоточен вокруг -18 дБ). Следует отметить, что,
предполагается, что размер первой передачи TB содержит все информационные биты до
быть закодированным; поэтому X равно размеру первого ТБ, отправленного процессом HARQ.
модель предполагает, что возможное присутствие битов четности в кодовых словах уже
учитываются на кривых уровня связи. Это означает, что как только минимальное значение R_{eff} равно
достигнута модель без учета прироста за счет передачи дополнительной четности
биты.
[изображение] Поведение процессов HARQ в LTE.UNINDENT

Часть HARQ, предназначенная для управления декодированием блоков HARQ, была удалена.
реализовано в LteHarqPhy и LteSpectrumPhy классы. Бывший отвечает за
сохранение информации HARQ для каждого активного процесса. Последний взаимодействует с
Лтемиеррормодел класс для оценки правильности полученных блоков и включает в себя
алгоритм обмена сообщениями, отвечающий за связь с объектом HARQ в планировщике
Результат декодирования. Эти сообщения инкапсулируются в
dlInfoListElement для DL и улИнфолистЭлемент для UL и отправляется через PUCCH и
PHICH соответственно с идеальной безошибочной моделью в соответствии с предположениями в их
реализация. Эскиз итерации между HARQ и стеком протоколов LTE в
представлен на рисунке: ссылка:fig-harq-архитектура.

Наконец, механизм HARQ всегда активен как на уровне MAC, так и на уровне PHY; однако в случае
планировщик не поддерживает HARQ, система продолжит работу с HARQ
функции заблокированы (т. е. буферы заполнены, но не используются). Эта реализация
характеристика дает обратную совместимость с планировщиками, реализованными до HARQ
интеграция.
[изображение] Взаимодействие между стеком протоколов HARQ и LTE. UNINDENT

MAC
Ресурс распределение Модель
Теперь мы кратко опишем, как обрабатывается распределение ресурсов в LTE, поясняя, как это происходит.
моделируется в симуляторе. Планировщик отвечает за создание определенных структур
под названием Данные Контролировать индикация (DCI), которые затем передаются PHY узла eNB в
подключенные UE, чтобы информировать их о выделении ресурсов для каждого подкадра
основа. Делая это в нисходящем направлении, планировщик должен заполнить некоторые определенные
поля структуры DCI со всей информацией, такой как: модуляция и кодирование
Используемая схема (MCS), размер транспортного блока MAC (TB) и битовая карта распределения
который идентифицирует, какие RB будут содержать данные, передаваемые eNB каждому пользователю.

Для сопоставления ресурсов с физическими RB мы принимаем локализованный отображение подход (см.
[Sesia2009], раздел 9.2.2.1); следовательно, в данном подкадре каждый RB всегда назначается
один и тот же пользователь в обоих слотах. Битовая карта распределения может быть закодирована в различных форматах; в
этой реализации мы рассмотрели распределение Тип 0 определено в [TS36213], согласно
к которым RB сгруппированы в группы блоков ресурсов (RBG) разного размера, определяемого
в зависимости от используемой конфигурации полосы пропускания передачи.

Для определенных значений пропускной способности не все RB можно использовать, так как размер группы не является
общий делитель группы. Это, например, случай, когда полоса пропускания равна
25 RB, что приводит к размеру RBG, равному 2 RB, и, следовательно, 1 RB не приведет к
адресный. В восходящем канале формат DCI отличается, так как только соседние RB могут
использоваться из-за модуляции SC-FDMA. Как следствие, все RB могут быть выделены
eNB независимо от конфигурации полосы пропускания.

Адаптивный Модуляция и Кодирование
Симулятор предоставляет две модели адаптивной модуляции и кодирования (AMC): одна основана на
Модель GSoC [Piro2011] и модель, основанная на модели физических ошибок (описанная в
следующие разделы).

Первая модель представляет собой модифицированную версию модели, описанной в [Piro2011], которая, в свою очередь,
вдохновлен [Seo2004]. Наша версия описана ниже. Пусть я обозначаю
общий пользователь, и пусть mma_i будет его SINR. Получаем спектральную эффективность \ta_i пользователя i
используя следующие уравнения:

Процедура, описанная в [R1-081483], используется для получения соответствующей схемы MCS.
спектральная эффективность квантуется на основе индикатора качества канала (CQI) с округлением до
наименьшее значение и сопоставляется с соответствующей схемой MCS.

Наконец, отметим, что есть некоторые расхождения между индексом MCS в [R1-081483]
и то, что указано в стандарте: [TS36213] Таблица 7.1.7.1-1 говорит, что индекс MCS
идет от 0 до 31, и 0 кажется действительной схемой MCS (размер TB не равен 0), но в
[R1-081483] первый полезный индекс MCS равен 1. Следовательно, чтобы получить значение, как предполагалось
Стандарт нам нужно вычесть 1 из индекса, указанного в [R1-081483].

Альтернативная модель основана на модели физической ошибки, разработанной для этого тренажера.
и объясняется в следующих подразделах. Эта схема способна адаптировать выбор MCS
к фактической производительности уровня PHY в соответствии с конкретным отчетом CQI. В соответствии с
их определение, индекс CQI назначается, когда один PDSCH TB с модуляцией
схема кодирования и кодовая скорость, соответствующие индексу CQI в таблице 7.2.3-1 [TS36213].
может быть получен с вероятностью ошибки менее 0.1. В случае широкополосных CQI,
эталонный TB включает все доступные RBG, чтобы иметь эталон на основе
все доступные ресурсы; в то время как для CQI поддиапазона эталонный TB имеет размер как RBG.

Транспорт Заблокировать модель
Модель транспортных блоков MAC (TB), предоставляемая симулятором, упрощена с помощью
соответствии со спецификациями 3GPP. В частности, класс, специфичный для симулятора
(PacketBurst) используется для агрегирования SDU MAC для достижения эквивалента симулятора.
ТБ, без соответствующей сложности реализации. Мультиплексирование
разные логические каналы на уровень RLC и обратно выполняются с использованием выделенного пакета
тег (LteRadioBearerTag), который выполняет функции, частично эквивалентные
заголовков MAC, определенных 3GPP.

Команда ФемтоФорум MAC Планировщик Интерфейс
В этом разделе описывается специфическая для ns-3 версия интерфейса LTE MAC Scheduler.
Спецификация опубликована FemtoForum [FFAPI].

Мы внедрили специальную версию интерфейса планировщика MAC-адресов FemtoForum для ns-3 [FFAPI].
как набор абстрактных классов C++; в частности, каждый примитив транслируется в C++
метод данного класса. Срок ввело здесь используется с тем же значением, принятым
в [FFAPI] и, следовательно, относится к процессу перевода логического интерфейса
спецификация конкретного языка программирования. Примитивы в [FFAPI] сгруппированы
на две группы: примитивы CSCHED, которые имеют дело с конфигурацией планировщика, и
Примитивы SCHED, отвечающие за выполнение планировщика. Кроме того, [ФФАПИ]
определяет примитивы двух разных типов: примитивы типа REQ идут от MAC к
Scheduler, а типы IND/CNF идут от планировщика к MAC. Чтобы перевести эти
характеристики в C++, мы определяем следующие абстрактные классы, которые реализуют Service
Точки доступа (SAP), которые будут использоваться для выдачи примитивов:

· В Ффмакшедсаппровидер class определяет все методы C++, соответствующие SCHED
примитивы типа REQ;

· В ФфМакШедSapUser class определяет все методы C++, соответствующие SCHED
примитивы типа CNF/IND;

· В Ффмаккшедсаппровидер class определяет все методы C++, которые соответствуют
примитивы CSCHED типа REQ;

· В ФфМаккшедSapUser class определяет все методы C++, соответствующие CSCHED
примитивы типа CNF/IND;

В интерфейсе планировщика MAC задействовано 3 блока: блок управления, блок подкадра.
и блок планировщика. Каждый из этих блоков обеспечивает одну часть интерфейса планировщика MAC.
На рисунке ниже показана взаимосвязь между блоками и SAP, определенными в нашем
реализация интерфейса планировщика MAC.
[Image]

В дополнение к вышеуказанным принципам были приняты следующие варианты конструкции:

· Определение классов интерфейса планировщика MAC соответствует соглашениям об именах.
нс-3 Стиль кодирования. В частности, мы следуем соглашению CamelCase для
примитивные названия. Например, примитив CSCHED_CELL_CONFIG_REQ переводится на
Ксчедселлконфигрек в нс-3 код.

· Те же соглашения об именах используются для параметров-примитивов. Как
примитивные параметры являются переменными-членами классов, они также имеют префикс
m_.

· относительно использования векторов и списков в структурах данных отметим, что [FFAPI] является
в значительной степени C-ориентированный API. Однако считается, что C++ используется в ns-3, и что
использование массивов C не рекомендуется, мы использовали векторы STL (std :: vector) для
реализация интерфейса планировщика MAC вместо использования массивов C в качестве
неявно предполагается способом написания [FFAPI].

· В C++ нельзя использовать члены с конструкторами и деструкторами. союзы. Следовательно, все
те структуры данных, которые называются союзы в [FFAPI] были определены как
Структуры в нашем коде.

На приведенном ниже рисунке показано, как интерфейс планировщика MAC используется в eNB.
[Image]

Пользовательская сторона как CSCHED SAP, так и SCHED SAP реализована в MAC eNB,
то есть в файле lte-enb-mac.cc. MAC-адрес eNB можно использовать с другим планировщиком.
реализации без изменений. На этом же рисунке в качестве примера показано, как
Реализован Round Robin Scheduler: для взаимодействия с MAC eNB, Round Robin Scheduler
планировщик реализует сторону провайдера интерфейсов SCHED SAP и CSCHED SAP. А
аналогичный подход можно использовать и для реализации других планировщиков. Описание каждого
реализации планировщика, которые мы предоставляем как часть нашего модуля моделирования LTE,
представлены в следующих подразделах.

Круглые Робин (РР) Планировщик
Планировщик Round Robin (RR), вероятно, является самым простым планировщиком из известных в литературе.
Он работает путем разделения доступных ресурсов между активными потоками, т. е. теми логическими
каналы, которые имеют непустую очередь RLC. Если количество RBG больше, чем
количество активных потоков, все потоки могут быть размещены в одном подкадре. В противном случае, если
количество активных потоков больше, чем количество RBG, не все потоки могут быть
запланировано в заданном подкадре; затем в следующем подкадре выделение начнется с
последний поток, который не был выделен. MCS, который должен быть принят для каждого пользователя, выполнен
в соответствии с полученными широкополосными CQI.

Что касается HARQ, RR реализует неадаптивную версию, что означает, что в
распределение попыток повторной передачи RR использует ту же конфигурацию распределения, что и
исходный блок, что означает сохранение тех же RBG и MCS. UE, которые выделены для
Повторные передачи HARQ не учитываются для передачи новых данных, если они
возможность передачи, доступная в том же TTI. Наконец, HARQ можно отключить с помощью
система атрибутов ns3 для обеспечения обратной совместимости со старыми тестовыми примерами и кодом,
в деталях:

Config::SetDefault("ns3::RrFfMacScheduler::HarqEnabled", BooleanValue (false));

Планировщик реализует фильтрацию CQI восходящей линии связи в соответствии с их природой с помощью
UlCqiФильтр атрибут, подробно:

· SRS_UL_CQI: во внутренних атрибутах хранится только CQI на основе SRS.

· PUSCH_UL_CQI: во внутренних атрибутах хранится только CQI на основе PUSCH.

· ALL_UL_CQI: все CQI хранятся в одном и том же внутреннем атрибуте (т. е. последний CQI
полученное сохраняется независимо от его природы).

пропорциональный Хорошая (ПФ) Планировщик
Планировщик Proportional Fair (PF) [Sesia2009] работает, планируя пользователя, когда его
мгновенное качество канала является высоким по сравнению с его собственным средним состоянием канала за
время. Пусть i,j обозначают общих пользователей; пусть t будет индексом подкадра, а k будет ресурсом
блочный индекс; пусть M_{i,k}(t) будет MCS, используемым пользователем i в ресурсном блоке k в соответствии с тем, что
сообщает модель AMC (см. Адаптивный Модуляция и Кодирование); наконец, пусть S(M, B)
размер ТБ в битах, как определено в [TS36213] для случая, когда число B ресурса
используются блоки. Достижимая скорость R_{i}(k,t) в бит/с для пользователя i в группе блоков ресурсов
k в подкадре t определяется как

где au — продолжительность TTI. В начале каждого подкадра t каждый RBG назначается
определенного пользователя. В частности, индекс 144}_{k}(t), которому назначен RBG k в момент времени t, равен
определяется как

где T_{j}(t) — пропускная способность в прошлом, воспринимаемая пользователем j. В соответствии с
вышеприведенный алгоритм планирования, пользователь может быть назначен различным RBG, которые могут быть
либо смежные, либо нет, в зависимости от текущего состояния канала и прошлых
пропускная способность T_{j}(t). Последний определяется в конце подкадра t
используя следующий подход экспоненциальной скользящей средней:

где lpha — постоянная времени (количество подкадров) экспоненциального перемещения
среднее значение, а 384s фактическая пропускная способность, достигнутая пользователем i в подкадре t. 360 это
измеряют по следующей методике. Сначала определяем MCS 840 j:

то определяем общее число 936 j:

где |

Что касается HARQ, PF реализует неадаптивную версию, что означает, что в
при распределении попыток повторной передачи планировщик использует одно и то же распределение
конфигурация исходного блока, что означает сохранение тех же RBG и MCS. UE
которые выделены для повторных передач HARQ, не учитываются для передачи новых
данные в случае, если они имеют возможность передачи, доступную в том же самом TTI. Наконец, ХАРК
можно отключить с помощью системы атрибутов ns3 для обеспечения обратной совместимости со старыми
тестовые примеры и код, подробно:

Config::SetDefault("ns3::PfFfMacScheduler::HarqEnabled", BooleanValue (false));

Максимальный Увеличить пропускную способность (МТ) Планировщик
Планировщик максимальной пропускной способности (MT) [FCapo2012] направлен на максимизацию общей пропускной способности.
из eNB. Он выделяет каждый RB пользователю, который может достичь максимально достижимой скорости в
текущий ТТИ. В настоящее время планировщик MT в NS-3 имеет две версии: частотная область
(FDMT) и во временной области (TDMT). В FDMT каждый планировщик TTI, MAC выделяет RBG для UE.
который имеет наивысшую достижимую скорость, рассчитанную по поддиапазону CQI. В TDMT каждый TTI, MAC
планировщик выбирает одно UE, которое имеет наивысшую достижимую скорость, рассчитанную с помощью широкополосного CQI.
Затем планировщик MAC выделяет все RBG этому UE в текущем TTI. Расчет
достижимая скорость в FDMT и TDMT такая же, как и в PF. Пусть i,j обозначает общий
пользователи; пусть t будет индексом подкадра, а k будет индексом блока ресурсов; пусть M_{i,k}(t) будет
MCS может использоваться пользователем i в ресурсном блоке k в соответствии с тем, что сообщает модель AMC (см.
Адаптивный Модуляция и Кодирование); наконец, пусть S(M, B) будет размером TB в битах, как определено в
[TS36213] для случая, когда используется количество блоков ресурсов B. Достижимая скорость
R_{i}(k,t) в бит/с для пользователя i в ресурсном блоке k в подкадре t определяется как

где au — продолжительность TTI. В начале каждого подкадра t каждый RB назначается
определенного пользователя. В частности, индекс 144}_{k}(t), которому назначен RB k в момент времени t, равен
определяется как

Когда несколько UE имеют одинаковую достижимую скорость, текущая реализация всегда
выбирает первое UE, созданное в сценарии. Хотя МТ может максимизировать пропускную способность ячейки, он
не может обеспечить справедливость для UE в плохом состоянии канала.

Увеличить пропускную способность в Средняя (ТТА) Планировщик
Планировщик пропускной способности к средней (TTA) [FCapo2012] можно рассматривать как промежуточный вариант.
между МТ и ПФ. Метрика, используемая в TTA, рассчитывается следующим образом:

Здесь R_{i}(k,t) в бит/с представляет собой достижимую скорость для пользователя i в ресурсном блоке k в
подрамник т. Метод расчета уже показан в MT и PF. При этом R_{i}(t) в
бит/с обозначает достижимую скорость для i в подкадре t. Разница между этими двумя
достижимые ставки, как получить MCS. Для R_{i}(k,t) MCS рассчитывается по CQI поддиапазона, в то время как
R_{i}(t) рассчитывается по широкополосному CQI. Планировщик TTA может быть реализован только по частоте
домен (FD), потому что достижимая скорость конкретного RBG связана только с FD
планирование.

Слепой Средняя Увеличить пропускную способность Планировщик
Планировщик средней пропускной способности вслепую [FCapo2012] стремится обеспечить равную пропускную способность для всех
UE под eNB. Метрика, используемая в TTA, рассчитывается следующим образом:

где T_{j}(t) — прошлые показатели пропускной способности, воспринимаемые пользователем j, и могут быть
рассчитывается тем же методом в планировщике PF. Во временной области слепая средняя пропускная способность
(TD-BET), планировщик выбирает UE с наивысшей метрикой приоритета и выделяет все RBG.
к этому УЭ. С другой стороны, в слепой средней пропускной способности частотной области (FD-BET)
каждый TTI планировщик сначала выбирает одно UE с наименьшим значением pastAverageThroughput (наибольшее
показатель приоритета). Затем планировщик назначает этому UE один RBG, он вычисляет ожидаемое
пропускную способность этого UE и использует ее для сравнения с предыдущей средней пропускной способностью T_{j}(t)
другие УЭ. Планировщик продолжает выделять RBG для этого UE до тех пор, пока не будет получен ожидаемый результат.
пропускная способность не является наименьшей среди прошлых средних пропускных способностей T_{j}(t) всех UE. Затем
планировщик будет использовать тот же способ для выделения RBG для нового UE с наименьшим прошлым
средняя пропускная способность T_{j}(t) до тех пор, пока все RBG не будут распределены по UE. Принцип, стоящий за этим
состоит в том, что в каждом TTI планировщик делает все возможное для достижения равной пропускной способности между
все УЭ.

Токены Банк Хорошая Очередь Планировщик
Token Bank Fair Queue (TBFQ) — это планировщик с поддержкой QoS, который является производным от дырявого ведра.
механизм. В TBFQ поток трафика пользователя i характеризуется следующими параметрами:

· t_{i}: скорость поступления пакетов (байт/сек)

· r_{i}: скорость генерации токена (байт/сек)

· p_{i}: размер пула токенов (байт)

· E_{i}: счетчик, который записывает количество токенов, заимствованных у токена или переданных ему.
банк по потоку i ; E_{i} может быть меньше нуля

Каждые K байт данных потребляют k токенов. Кроме того, TBFQ поддерживает общий банк токенов (B), чтобы
балансировать трафик между разными потоками. Если скорость генерации токена r_{i} больше, чем
скорость прибытия пакетов t_{i}, то к маркеру добавляются токены, переполненные из пула токенов.
банка, а E_{i} увеличивается на ту же сумму. В противном случае поток мне нужно вывести
токены из банка токенов на основе метрики приоритета frac{E_{i}}{r_{i}}, а E_{i}
уменьшилось. Очевидно, что пользователь вносит больший вклад в банк токенов, имеет более высокий приоритет.
брать токены; с другой стороны, пользователь берет взаймы больше токенов у банка, у которого меньше
приоритет для продолжения вывода токенов. Таким образом, в случае нескольких пользователей, имеющих
такая же скорость генерации токенов, скорость трафика и размер пула токенов, пользователь страдает от более высокой
интерференция имеет больше возможностей заимствовать токены у банка. Кроме того, TBFQ может контролировать
трафика, установив скорость генерации маркера для ограничения пропускной способности. Кроме того,
TBFQ также поддерживает следующие три параметра для каждого потока:

· Лимит долга d_{i}: если E_{i} ниже этого порога, пользователь i не может больше брать токены
из банка. Это необходимо для предотвращения заимствования вредоносным UE слишком большого количества токенов.

· Кредитный лимит c_{i}: максимальное количество токенов UE, которое я могу одолжить в банке за один раз.
времени.

· Кредитный порог C: как только E_{i} достигает предела долга, UE i должен хранить токены C в банке
для дальнейшего заимствования токена в банке.

LTE в NS-3 имеет две версии планировщика TBFQ: TBFQ в частотной области (FD-TBFQ) и временную.
домен TBFQ (TD-TBFQ). В FD-TBFQ планировщик всегда выбирает UE с самой высокой метрикой и
выделяет RBG с самым высоким CQI поддиапазона до тех пор, пока в буфере RLC UE не останется пакетов
или выделяются все RBG [FABokhari2009]. В TD-TBFQ после выбора UE с максимальным
метрике, он выделяет все RBG этому UE, используя широкополосный CQI [WKWong2004].

приоритет Поставьте Планировщик
Планировщик набора приоритетов (PSS) — это планировщик с поддержкой QoS, который сочетает в себе временную область (TD) и
операции планирования пакетов в частотной области (FD) в одном планировщике [GMonghal2008]. Это
контролирует справедливость среди UE по заданной целевой скорости передачи данных (TBR).

В части планировщика TD PSS сначала выбирает UE с непустым буфером RLC, а затем разделяет их
на два набора на основе TBR:

· набор 1: UE, чья средняя пропускная способность в прошлом меньше, чем TBR; Планировщик TD вычисляет
их метрика приоритета в стиле слепой равной пропускной способности (BET):

· набор 2: UE, чья средняя пропускная способность в прошлом больше (или равна), чем TBR; Планировщик ТД
вычисляет их метрику приоритета в стиле Proportional Fair (PF):

UE, принадлежащие набору 1, имеют более высокий приоритет, чем устройства из набора 2. Тогда PSS выберет
N_{mux} UE с самой высокой метрикой в ​​двух наборах и направить эти UE планировщику FD. В ПСС,
Планировщик FD выделяет RBG k для UE n, которое достигает максимальной выбранной метрики. Два планировщика PF
используются в планировщике PF:

· Запланирована пропорциональная ярмарка (PFsch)

· Интерференция несущей к среднему значению (CoIta)

где Tsch_{j}(t) - аналогичная пропускная способность в прошлом, воспринимаемая пользователем j, с
разница в том, что он обновляется только тогда, когда действительно обслуживается i-й пользователь. CoI[j,k] является
оценка SINR на RBG k для UE j. И PFsch, и CoIta предназначены для развязки FD.
метрика из планировщика TD. Кроме того, планировщик PSS FD также предоставляет весовую метрику W[n]
для помощи в контроле справедливости в случае небольшого количества UE.

где T_{j}(t) — прошлые показатели пропускной способности, воспринимаемые пользователем j . Следовательно, на
RBG k планировщик FD выбирает UE j, которое максимизирует произведение частоты
метрика домена (Msch, MCoI) по весу W[n]. Эта стратегия гарантирует пропускную способность
UE более низкого качества склоняются к TBR.

Config::SetDefault("ns3::PfFfMacScheduler::HarqEnabled", BooleanValue (false));

Планировщик реализует фильтрацию CQI восходящей линии связи в соответствии с их природой с помощью
UlCqiФильтр атрибут, подробно:

· SRS_UL_CQI: во внутренних атрибутах хранится только CQI на основе SRS.

· PUSCH_UL_CQI: во внутренних атрибутах хранится только CQI на основе PUSCH.

· ALL_UL_CQI: все CQI хранятся в одном и том же внутреннем атрибуте (т. е. последний CQI
полученное сохраняется независимо от его природы).

Канал и QoS Осознавая Планировщик
Планировщик Channel and QoS Aware (CQA) [Bbojovic2014] представляет собой планирование нисходящего канала LTE MAC.
алгоритм, учитывающий задержку начала строки (HOL), параметры GBR и канал
качество в разных поддиапазонах. Планировщик CQA основан на совместном планировании TD и FD.

В TD (на каждом TTI) планировщик CQA группирует пользователей по приоритету. Цель
группировка заключается в том, чтобы обеспечить планирование FD для рассмотрения в первую очередь потоков с наивысшим значением HOL.
задерживать. Метрика группировки m_{td} для пользователя j=1,...,N определяется следующим образом:

где d_{hol}^{j}(t) — текущее значение задержки HOL потока j, а g — группировка
параметр, определяющий гранулярность групп, т.е. количество потоков,
будет учитываться в итерации планирования FD.

Группы потоков, выбранные в итерации TD, направляются в планирование FD.
начиная с потоков с наибольшим значением метрики m_{td} до тех пор, пока все RBG не будут
присваивается в соответствующем TTI. В FD для каждого RBG k=1,...,K планировщик CQA
назначает текущую RBG пользователю j, имеющему максимальное значение метрики FD, которую мы
определить следующим образом:

где m_{GBR}^j(t) вычисляется следующим образом:

где GBR^j — битовая скорость, указанная в ЭПС-носителе потока j, т. е. R j ( ) обеспечивает пропускную способность,
рассчитывается со скользящим средним, r^{j}(t) — пропускная способность, достигнутая в момент времени t,
и lpha — коэффициент такой, что 0 lpha ..sp Для m_{ca}^{(k,j)}(t) рассмотрим два
разные метрики: m_{pf}^{(k,j)}(t) и m_{ff}^{(k,j)}(t). m_{pf} — пропорциональный
Справедливая метрика, которая определяется следующим образом:

где R_e^{(k,j)}(t) — предполагаемая достижимая пропускная способность пользователя j по RBG k
рассчитывается по схеме Adaptive Modulation and Coding (AMC), которая отображает канал
значение индикатора качества (CQI) к размеру транспортного блока в битах.

Другая метрика осведомленности о канале, которую мы рассматриваем, — это m_{ff}, которая предлагается в
[GMonghal2008] и представляет собой усиление частотно-избирательного замирания по сравнению с RBG k для пользователя.
j и рассчитывается следующим образом:

где CQI^{(k,j)}(t) — последнее сообщенное значение CQI от пользователя j для k-го RBG.

Пользователь может выбрать, будет ли использоваться m_{pf} или m_{ff}, установив атрибут
ns3::CqaFfMacScheduler::CqaMetric соответственно "КкаПф" or "КкаФф".

Случайно О компании
Модель LTE включает в себя модель процедуры произвольного доступа, основанную на некотором упрощении.
предположения, которые подробно описаны ниже для каждого из сообщений и сигналов
описано в спецификациях [TS36321].

· Случайно О компании (РА) преамбула: в реальных системах LTE это соответствует схеме Zadoff-Chu
(ZC) последовательность, использующая один из нескольких доступных форматов и отправляемая в слоты PRACH.
который в принципе может пересекаться с PUSCH. Индекс конфигурации PRACH 14
предполагается, т. е. преамбулы могут быть отправлены с любым номером системного кадра и номером подкадра.
Преамбула RA моделируется с использованием класса LteControlMessage, т. е. как идеальная
сообщение, которое не потребляет никаких радиоресурсов. Коллизия преамбулы
передача несколькими UE в одной и той же ячейке моделируется с использованием протокола
интерференционная модель, т. е. всякий раз, когда две или более идентичных преамбул передаются в
одной и той же соте в одном и том же TTI, ни одна из этих идентичных преамбул не будет получена
eNB. Кроме этой модели коллизий, никакая модель ошибок не связана с
прием преамбулы RA.

· Случайно О компании Режимы секции мощности (РАР): в реальных системах LTE это специальный MAC PDU, отправляемый
ДЛ-Щ. Поскольку элементы управления МАС моделируются в симуляторе неточно.
(только RLC и выше PDU), RAR моделируется как LteControlMessage, который
не потреблять никаких радиоресурсов. Тем не менее, во время процедуры RA LteEnbMac будет
запросить у планировщика выделение ресурсов для RAR с помощью FF MAC
Примитив планировщика SCHED_DL_RACH_INFO_REQ. Следовательно, улучшенный планировщик
реализация (на данный момент недоступная) может выделять радиоресурсы для
RAR, тем самым моделируя потребление радиоресурсов для передачи
РАР.

· Сообщение 3: в реальных системах LTE это SDU RLC TM, отправленный по указанным ресурсам.
в Гранте UL в RAR. В симуляторе это моделируется как настоящий RLC TM RLC
PDU, чьи ресурсы UL выделяются планировщиком при вызове
SCHED_DL_RACH_INFO_REQ.

· раздор Разрешение (КР): в реальной системе LTE фаза CR необходима для
случай, когда два или более UE отправили одну и ту же преамбулу RA в одном и том же TTI, а eNB был
в состоянии обнаружить эту преамбулу, несмотря на коллизию. Поскольку это событие не
возникают из-за модели помех протокола, используемой для приема преамбул RA,
фаза CR не моделируется в симуляторе, т. е. CE MAC CR никогда не отправляется
eNB и UE считают RA успешным после приема RAR. Как
Как следствие, радиоресурсы, потребляемые для передачи CR MAC CE,
не моделируется.

Figure Последовательность диаграмма of на основе конкуренции MAC Случайно О компании процедуры и Последовательность
диаграмма of Неконфликтный MAC Случайно О компании процедуры показывает последовательность
диаграммы соответственно произвольного доступа MAC на основе конкуренции и без конкуренции
процедуры, подчеркивая взаимодействие между MAC и другими объектами.
[изображение] Диаграмма последовательности процедуры произвольного доступа MAC на основе конкуренции. UNINDENT
[изображение] Диаграмма последовательности произвольного доступа MAC без конкуренции
процедура.БЕЗ ИНФОРМАЦИИ

RLC
Обзор
Объект RLC указан в технической спецификации 3GPP [TS36322] и содержит
три разных типа RLC: прозрачный режим (TM), режим без подтверждения (UM) и
Подтвержденный режим (AM). Симулятор включает по одной модели для каждого из этих объектов.

Объекты RLC обеспечивают интерфейс службы RLC для верхнего уровня PDCP и MAC.
служебный интерфейс к нижнему уровню MAC. Объекты RLC используют сервисный интерфейс PDCP.
от верхнего уровня PDCP и интерфейс службы MAC от нижнего уровня MAC.

Figure Реализация Модель of ПДКП, RLC и MAC лиц и SAP показывает
модель реализации объектов RLC и ее взаимосвязь со всеми другими объектами
и службы в стеке протоколов.
[изображение] Модель реализации объектов PDCP, RLC и MAC и SAP. UNINDENT

Услуга Интерфейсы
RLC Услуга Интерфейс
Интерфейс службы RLC разделен на две части:

· В РлкСапПровидер часть предоставляется уровнем RLC и используется верхним уровнем PDCP
и

· В РлкСапУсер часть обеспечивается верхним уровнем PDCP и используется уровнем RLC.

Объекты RLC единой системы обмена сообщениями и AM предоставляют один и тот же сервисный интерфейс RLC для верхнего уровня.
Уровень PDCP.

RLC Услуга Примитивы
В следующем списке указано, какие сервисные примитивы предоставляются службой RLC.
интерфейсы:

· RlcSapProvider:: TransmitPdcpPdu

· Объект PDCP использует этот примитив для отправки PDU PDCP нижестоящему объекту RLC.
в передатчике

· Рлксапусер:: ресиверпдкпду

· Объект RLC использует этот примитив для отправки PDU PDCP вышестоящему объекту PDCP.
в узле-получателе

MAC Услуга Интерфейс
Интерфейс службы MAC разделен на две части:

· В MacSapProvider часть предоставляется уровнем MAC и используется верхним уровнем RLC
и

· В Пользователь MacSap часть обеспечивается верхним уровнем RLC и используется уровнем MAC.

MAC Услуга Примитивы
В следующем списке указано, какие служебные примитивы предоставляются службой MAC.
интерфейсы:

· MacSapProvider:: TransmitPdu

· Объект RLC использует этот примитив для отправки PDU RLC на нижестоящий объект MAC в
узел передатчика

· MacSapProvider::ReportBufferStatus

· Объект RLC использует этот примитив, чтобы сообщить объекту MAC размер ожидающих
буферы в передатчике

· MacSapUser::NotifyTxOpportunity

· Объект MAC использует этот примитив для уведомления объекта RLC о передаче
Возможность

· МакСапУсер::РецеивеПду

· Объект MAC использует этот примитив для отправки PDU RLC вышестоящему объекту RLC.
в узле-получателе

AM RLC
Объясняется обработка передачи данных в объекте RLC режима подтверждения (AM).
в разделе 5.1.3 [TS36322]. В этом разделе мы опишем некоторые детали
реализация объекта RLC.

Буферы для передавать операции
Наша реализация объекта AM RLC поддерживает 3 буфера для операций передачи:

· Автоматическая коробка передач Buffer: это очередь RLC SDU. Когда объект AM RLC получает SDU
в сервисном примитиве TransmitPdcpPdu из вышестоящего объекта PDCP он ставит его в очередь
в буфере передачи. Ставим ограничение на размер буфера RLC и просто молча
отбрасывать SDU, когда буфер заполнен.

· Передаваемое БРП Buffer: это очередь переданных RLC PDU, для которых
ACK/NACK еще не получен. Когда объект AM RLC отправляет PDU на MAC
сущности, он также помещает копию переданного PDU в буфер переданных PDU.

· ретранслировать Buffer: это очередь RLC PDU, которые рассматриваются для
повторная передача (т. е. они были NACK). Объект AM RLC перемещает этот PDU в
Буфер повторной передачи, когда он повторно передает PDU из буфера передачи.

передавать операции in нисходящей линии связи
Следующая диаграмма последовательности показывает взаимодействие между различными объектами (RRC,
PDCP, AM RLC, MAC и планировщик MAC) eNB в нисходящем канале для передачи данных
коммуникации.

Figure Последовательность диаграмма of данным PDU в мозге in нисходящей линии связи показывает, как верхние слои
отправлять PDU данных и как поток данных обрабатывается различными объектами/службами
стек протоколов LTE.
[изображение] Диаграмма последовательности передачи PDU данных в нисходящем канале. UNINDENT

Объект PDCP вызывает Передать_PDCP_PDU СЕРВИС примитивный чтобы отправить данные
БРП. Объект AM RLC обрабатывает этот сервисный примитив в соответствии с данными AM.
процедуры передачи, определенные в разделе 5.1.3 [TS36322].

Когда Передать_PDCP_PDU сервисный примитив, объект AM RLC выполняет
следующие операции:

· Поместите данные SDU в буфер передачи.

· Вычислить размер буферов (как вычисляется размер буферов, будет
объяснил потом).

· Позвонить Report_Buffer_Status служебный примитив объекта MAC eNB, чтобы
уведомлять объект MAC eNB о размерах буферов объекта AM RLC. Затем
Объект MAC eNB обновляет состояние буфера в планировщике MAC, используя
Сервисный примитив SchedDlRlcBufferReq API планировщика MAC-адресов FF.

Впоследствии, когда планировщик MAC решает, что некоторые данные могут быть отправлены, объект MAC
уведомляет об этом объект RLC, т. е. вызывает Notify_Tx_Opportunity сервисный примитив,
затем объект AM RLC делает следующее:

· Создайте единый PDU данных путем сегментации и/или объединения SDU в
Буфер передачи.

· Переместите PDU данных из буфера передачи в буфер переданных PDU.

· Обновите переменные состояния в соответствии с разделом 5.1.3.1.1 [TS36322].

· Позвонить Передача_ПДУ примитив для отправки PDU данных на объект MAC.

ретранслировать in нисходящей линии связи
Диаграмма последовательности на рисунке Последовательность диаграмма of данным PDU ретрансляция in нисходящей линии связи
показывает взаимодействие между различными объектами (AM RLC, MAC и планировщик MAC)
eNB в нисходящей линии связи, когда объекты PDU данных должны быть повторно переданы объектом AM RLC.
[изображение] Диаграмма последовательности повторной передачи данных PDU по нисходящей линии связи. UNINDENT

Передающий объект AM RLC может принимать блоки STATUS PDU от равноправного объекта AM RLC.
STATUS PDU отправляются в соответствии с разделом 5.3.2 [TS36322] и обработкой
прием производится в соответствии с разделом 5.2.1 [TS36322].

Когда PDU данных повторно передаются из буфера переданных PDU, они также перемещаются в
буфер ретрансляции.

передавать операции in восходящей
Диаграмма последовательности на рисунке Последовательность диаграмма of данным PDU в мозге in восходящей сериал
взаимодействия между различными объектами UE (RRC, PDCP, RLC и MAC) и
eNB (MAC и планировщик) в восходящей линии связи, когда PDU данных отправляются верхними уровнями.
[изображение] Диаграмма последовательности передачи PDU данных в восходящем канале. UNINDENT

Это похоже на диаграмму последовательности в нисходящей линии связи; основное отличие в том, что в этом
случай, когда Report_Buffer_Status отправляется из MAC UE в планировщик MAC в eNB
в эфире по каналу управления.

ретранслировать in восходящей
Диаграмма последовательности на рисунке Последовательность диаграмма of данным PDU ретрансляция in восходящей сериал
взаимодействия между различными объектами UE (AM RLC и MAC) и eNB
(MAC) в восходящей линии связи, когда объекты PDU данных должны быть повторно переданы объектом AM RLC.
[изображение] Диаграмма последовательности повторной передачи PDU данных в восходящем канале. UNINDENT

Расчет of буфер размер
Буфер передачи содержит SDU RLC. PDU RLC — это один или несколько сегментов SDU плюс
Заголовок РЛК. Размер заголовка RLC одного PDU RLC зависит от количества SDU.
сегментов, содержащихся в PDU.

Стандарт 3GPP (раздел 6.1.3.1 [TS36321]) ясно говорит, что для восходящего канала
Заголовки RLC и MAC не учитываются в размере буфера, который должен сообщаться как часть
отчет о состоянии буфера. Для нисходящей линии поведение не указано. Ни один
[FFAPI] указывает, как это сделать. Наша модель RLC работает, предполагая, что расчет
размер буфера в нисходящем канале делается точно так же, как и в аплинке, т.е. без учета
размер заголовка RLC и MAC.

Заметим, что этот выбор влияет на взаимодействие с планировщиком MAC, поскольку в
ответ на Notify_Tx_Opportunity служебный примитив, ожидается, что RLC создаст
Размер PDU не превышает размера, запрошенного MAC, включая служебные данные RLC. Следовательно, ненужный
фрагментация может произойти, если (например) MAC уведомляет о передаче, точно равной
размер буфера, ранее сообщенный RLC. Мы предполагаем, что это оставлено планировщику
реализовать интеллектуальные стратегии выбора размера передачи
возможность, чтобы в конечном итоге избежать неэффективности ненужной фрагментации.

конкатенация и Сегментация
Объект AM RLC генерирует и отправляет ровно один PDU RLC для каждой передачи.
возможность, даже если она меньше, чем размер, сообщаемый возможностью передачи.
Так, например, если должен быть отправлен STATUS PDU, то только этот PDU будет отправлен в этом
возможность передачи.

Сегментация и объединение для очереди SDU объекта AM RLC выполняются так же.
философия аналогична тем же процедурам объекта RLC единой системы обмена сообщениями, но есть новые переменные состояния
(см. раздел 36322 [TS7.1]) присутствует только в объекте AM RLC.

Отмечается, что согласно спецификациям 3GPP конкатенация для
Буфер ретрансляции.

Повторная сегментация
Текущая модель объекта AM RLC не поддерживает повторную сегментацию
буфер ретрансляции. Вместо этого объект AM RLC просто ожидает получения достаточно большого
возможность передачи.

Не поддерживается функции
Мы не поддерживаем следующие процедуры [TS36322]:

· «Отправить указание об успешной доставке RLC SDU» (см. раздел 5.1.3.1.1)

· «Указать вышестоящим уровням, что достигнута максимальная повторная передача» (см. раздел
5.2.1)

· «Процедуры списания SDU» (см. раздел 5.3)

· «Процедура восстановления» (см. раздел 5.4)

Мы не поддерживаем какие-либо дополнительные примитивы RLC SAP для объекта AM RLC. В
специфический:

· PDCP не уведомляет об аннулировании SDU

· отсутствие уведомления об успешной/неудачной доставке объектом AM RLC объекту PDCP

UM RLC
В этом разделе мы описываем реализацию объекта RLC в режиме без подтверждения (UM).

передавать операции in нисходящей линии связи
Операции передачи UM RLC аналогичны операциям AM RLC ранее.
описано в разделе передавать операции in нисходящей линии связи, с той разницей, что после
спецификациям [TS36322], повторная передача не выполняется, а STATUS
PDU.

передавать операции in восходящей
Операции передачи по восходящей линии аналогичны операциям по нисходящей линии, с основным
Разница в том, что Report_Buffer_Status отправляется от MAC UE к планировщику MAC в
eNB по радиоканалу с использованием канала управления.

Расчет of буфер размер
Вычисление размера буфера для RLC единой системы обмена сообщениями выполняется с использованием того же подхода, что и для
AM RLC, см. раздел Расчет of буфер размер для соответствующих
описание.

TM RLC
В этом разделе мы описываем реализацию объекта RLC в прозрачном режиме (TM).

передавать операции in нисходящей линии связи
В симуляторе TM RLC по-прежнему предоставляет верхним уровням тот же сервисный интерфейс.
предоставляется объектами AM и UM RLC на уровень PDCP; на практике этот интерфейс
используется объектом RRC (не объектом PDCP) для передачи SDU RLC. Этот выбор
мотивировано тем, что услуги, предоставляемые TM RLC верхним уровням,
согласно [TS36322], является подмножеством объектов, предоставляемых объектами UM и AM RLC для
уровень PDCP; следовательно, для простоты мы повторно использовали один и тот же интерфейс.

Операции передачи в нисходящей линии связи выполняются следующим образом. Когда
Передать_PDCP_PDU СЕРВИС примитивный вызывается верхними уровнями, TM RLC выполняет
следующие:

· поместить SDU в буфер передачи

· вычислить размер буфера передачи

· позвонить в Report_Buffer_Status служебный примитив объекта MAC eNB

Впоследствии, когда планировщик MAC решает, что некоторые данные могут быть отправлены логическим
канал, которому принадлежит объект TM RLC, объект MAC уведомляет об этом объект TM RLC
сущность, позвонив в Notify_Tx_Opportunity сервисный примитив. При получении этого
примитива, объект TM RLC выполняет следующие действия:

· если возможность TX имеет размер, который больше или равен размеру
головной SDU в буфере передачи

· исключить SDU из очереди из буфера передачи

· создать один PDU RLC, который полностью содержит этот SDU без какого-либо заголовка RLC

· Позвонить Передача_ПДУ примитив для отправки PDU RLC на объект MAC.

передавать операции in восходящей
Операции передачи по восходящей линии аналогичны операциям по нисходящей линии, с основным
разница в том, что возможность передачи также может возникнуть из-за присвоения UL
GRANT как часть процедуры произвольного доступа без явного отчета о состоянии буфера.
выданный организацией TM RLC.

Расчет of буфер размер
Согласно спецификациям [TS36322], TM RLC не добавляет никаких заголовков RLC в PDU.
передается. Из-за этого размер буфера, сообщаемый на уровень MAC,
рассчитывается просто путем суммирования размера всех пакетов в буфере передачи, таким образом
уведомляя MAC о точном размере буфера.

SM RLC
В дополнение к реализациям AM, UM и TM, созданным по образцу 3GPP
спецификации предоставляется упрощенная модель RLC, которая называется режимом насыщения (SM)
РЛК. Эта модель RLC не принимает PDU от любого вышележащего уровня (например, PDCP); скорее,
SM RLC заботится о генерации PDU RLC в ответ на уведомление о
возможности передачи, о которых сообщает MAC. Другими словами, SM RLC моделирует
условия насыщения, т. е. предполагается, что буфер RLC всегда полон и может
генерировать новый PDU всякий раз, когда планировщик уведомляет об этом.

SM RLC используется для упрощенных сценариев моделирования, в которых используется только модель LTE Radio.
используется без EPC и, следовательно, без какой-либо поддержки IP-сетей. Мы отмечаем, что
хотя SM RLC является нереалистичной моделью трафика, она все же позволяет правильно
моделирование сценариев с несколькими потоками, принадлежащими разным (не в реальном времени) QoS
классы, чтобы проверить производительность QoS, полученную различными планировщиками. Это может
быть выполнено, поскольку задача Планировщика состоит в том, чтобы назначать ресурсы передачи на основе
характеристики (например, гарантированная скорость передачи данных) каждого радиоканала, которые указаны
после определения каждого носителя в программе моделирования.

Что касается планировщиков, предназначенных для работы с QoS-трафиком в реальном времени, который имеет ограничения по задержке,
SM RLC, вероятно, не является подходящим выбором. Это связано с отсутствием фактического
SDU RLC (замененные искусственным созданием отчетов о состоянии буфера) не позволяют
можно предоставить планировщику содержательную информацию о начальной задержке, которая
часто является предпочтительной метрикой для реализации политик планирования в режиме реального времени.
потоки трафика. Для моделирования и тестирования таких планировщиков целесообразно использовать
либо модели UM, либо модели AM RLC.

ПДКП
ПДКП Модель Обзор
Справочным документом для спецификации объекта PDCP является [TS36323]. С уважением
В соответствии с этой спецификацией модель PDCP, реализованная в симуляторе, поддерживает только
следующие функции:

· передача данных (плоскость пользователя или плоскость управления);

· сопровождение PDCP SN;

· передача статуса SN (для использования при передаче обслуживания);

В настоящее время не поддерживаются следующие функции:

· сжатие заголовков и распаковка потоков данных IP по протоколу ROHC;

· последовательная доставка PDU верхнего уровня при переустановке нижних уровней;

· дублирование устранения SDU нижнего уровня при переустановке нижних уровней для
однонаправленные радиоканалы отображаются на RLC AM;

· шифрование и дешифрование данных плоскости пользователя и данных плоскости управления;

· защита целостности и проверка целостности данных плоскости управления;

· сброс по таймеру;

· удаление дубликатов.

ПДКП Услуга Интерфейс
Интерфейс службы PDCP разделен на две части:

· В PdcpSapProvider часть предоставляется уровнем PDCP и используется верхним уровнем
и

· В PdcpSapUser часть обеспечивается верхним уровнем и используется уровнем PDCP.

ПДКП Услуга Примитивы
В следующем списке указано, какие служебные примитивы предоставляются службой PDCP.
интерфейсы:

· PdcpSapProvider:: TransmitPdcpSdu

· Объект RRC использует этот примитив для отправки PDU RRC нижестоящему объекту PDCP.
в передатчике

· ПдкпСапусер::РецеивеПдкпСду

· Объект PDCP использует этот примитив для отправки PDU RRC вышестоящему объекту RRC.
в узле-получателе

РКР
Особенности
Модель RRC, реализованная в тренажере, обеспечивает следующие функциональные возможности:

· генерация (в eNB) и интерпретация (в UE) системной информации (в
в частности основной информационный блок и, на момент написания этой статьи, только системный
Информационный блок Тип 1 и 2)

· начальный выбор ячейки

· Процедура установления RRC-соединения

· Процедура реконфигурации RRC, поддерживающая следующие варианты использования: + реконфигурация
индекса конфигурации SRS + реконфигурация режима PHY TX (MIMO) +
реконфигурация измерений UE + настройка однонаправленного радиоканала данных + передача обслуживания

· Повторное установление соединения RRC, поддерживающее следующие варианты использования: + передача обслуживания

Архитектура
Модель RRC делится на следующие компоненты:

· субъекты RRC LteUeRrc и Лтеенбрррк, которые реализуют конечные автоматы
Объекты RRC соответственно в UE и eNB;

· СПД RRC Лтеуеррксаппровидер, Лтеуеррксапусер, Лтеэнбррксаппровидер,
Лтеенбрррксапусер, которые позволяют объектам RRC отправлять и получать сообщения RRC и
информационные элементы;

· классы протокола RRC LteUeRrcProtocolIdeal, LteEnbrRrcПротоколИдеал,
LteUeRrcПротоколРеал, LteEnbrRrcПротоколРеал, которые реализуют две разные модели для
передача RRC-сообщений.

Кроме того, компоненты RRC используют различные другие SAP для взаимодействия с остальными.
стека протоколов. Представление всех используемых SAP представлено в
данные LTE радио протокол стек архитектура для UE on данным самолет, LTE радио
протокол стек архитектура для UE on контроль самолет, LTE радио протокол стек
архитектура для eNB on данным самолет и LTE радио протокол стек архитектура для
eNB on контроль самолет.

UE РКР Область Машина
На рисунке UE РКР Область Машина представляем конечный автомат как реализованный в RRC UE
организация.
[изображение] UE RRC State Machine.UNINDENT

Следует отметить, что большинство состояний являются переходными, т. е. как только UE переходит в одно
состояний CONNECTED, он никогда не переключится обратно ни в одно из состояний IDLE. Этот выбор
делается по следующим причинам:

· как обсуждалось в разделе Дизайн Критерии, в центре внимания моделирования LTE-EPC
модель находится в режиме CONNECTED

· Отказ радиоканала в настоящее время не моделируется, как обсуждалось в разделе Радио Ссылка
Ошибка, поэтому UE не может перейти в режим ожидания из-за отказа радиоканала.

· Освобождение соединения RRC в настоящее время никогда не инициируется ни EPC, ни NAS.

Тем не менее, мы решили явно моделировать состояния IDLE, потому что:

· для передачи обслуживания требуется реалистичная конфигурация RRC UE, что является обязательной функцией,
а для более чистой реализации имеет смысл использовать тот же UE RRC
конфигурация также для первоначального установления соединения

· упрощается реализация выбора ячеек в режиме ожидания в будущем, что
очень желательная функция

ENB РКР Область Машина
eNB RRC поддерживает состояние для каждого UE, которое подключено к соте. Из
с точки зрения реализации, состояние каждого UE содержится в экземпляре
Класс УМенеджер. Конечный автомат представлен на рисунке ENB РКР Область Машина для каждый
UE.
[изображение] Конечный автомат ENB RRC для каждого UE.UNINDENT

Начальный Ячейка Выбор
Первоначальный выбор соты представляет собой процедуру режима IDLE, выполняемую UE, когда оно еще не
размещен или присоединен к eNodeB. Цель процедуры – найти подходящую ячейку
и подключитесь к нему, чтобы получить доступ к сотовой сети.

Обычно это делается в начале моделирования, как показано на рис. Образец работает of
начальный ячейка выбор in UE и синхронизация of Связанный События ниже. Временная диаграмма на
левая сторона иллюстрирует случай, когда первоначальный выбор ячейки успешен с первой попытки,
в то время как диаграмма справа предназначена для случая, когда он терпит неудачу с первой попытки и
получится со второй попытки. Синхронизация предполагает использование реальной модели протокола RRC (см. РКР
протокол ухода) и отсутствие ошибок передачи.
[изображение] Примеры запуска начального выбора соты в UE и синхронизация соответствующих
события.UNINDENT

Функциональность основана на спецификациях режима 3GPP IDLE, например, в [TS36300],
[TS36304] и [TS36331]. Однако правильная реализация режима IDLE по-прежнему отсутствует.
в симуляторе, поэтому оставляем за собой несколько упрощающих допущений:

· несколько несущих частот не поддерживаются;

· множественные идентификаторы сети наземной подвижной связи общего пользования (PLMN) (т. е.
операторы) не поддерживается;

· измерения RSRQ не используются;

· выбор ячейки сохраненной информации не поддерживается;

· Состояние «Выбор любой ячейки» и переход в приемлемую ячейку не поддерживаются;

· пометка ячейки как запрещенной или зарезервированной не поддерживается;

· повторный выбор соты не поддерживается, поэтому UE не может
другая ячейка после размещения начального лагеря; а также

· Белый список закрытой группы абонентов (CSG) UE содержит только один идентификатор CSG.

Также обратите внимание, что первоначальный выбор ячейки доступен только для моделирования с поддержкой EPC.
При моделировании только для LTE необходимо использовать метод ручного подключения. См. раздел
sec-network-attach Пользовательской документации для получения дополнительной информации об их различиях
в использовании.

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

Ячейка Поиск
Поиск сот направлен на обнаружение окружающих сот и измерение уровня принимаемого сигнала.
из каждой из этих ячеек. Одна из этих ячеек станет точкой входа UE для присоединения к сети.
сотовая сеть.

Измерения основаны на RSRP принятого PSS, усредненного фильтрацией уровня 1,
и выполняется уровнем PHY, как описано ранее более подробно в разделе UE PHY
измерения Модель. PSS передается eNodeB по 72 центральным поднесущим
Канал DL (раздел 5.1.7.3 [TS36300]), поэтому мы моделируем поиск соты для работы с использованием DL.
пропускная способность 6 РБ. Обратите внимание, что измерения RSRQ на данный момент недоступны.
в симуляции. Как следствие, LteUePhy:: RsrqUeMeasThreshold атрибут не
применять во время поиска соты.

Используя измеренный RSRP, объект PHY может генерировать список обнаруженных ячеек,
каждый с соответствующим идентификатором соты и усредненным значением RSRP. Этот список периодически обновляется
через CPHY SAP объекту RRC в виде отчета об измерениях.

Объект RRC проверяет отчет и просто выбирает ячейку с самым сильным RSRP, т.к.
также указано в разделе 5.2.3.1 [TS36304]. Затем он инструктирует объект PHY, чтобы
синхронизироваться с этой конкретной ячейкой. Фактическая рабочая полоса пропускания соты по-прежнему
в настоящее время неизвестно, поэтому объект PHY прослушивает только минимальную полосу пропускания 6 RB.
Тем не менее, объект PHY сможет получать системные широковещательные сообщения от этого
конкретного eNodeB, который является темой следующего подраздела.

Трансляции of Система Информация
Блоки системной информации широковещательно передаются eNodeB на UE в предопределенные интервалы времени,
адаптировано из раздела 5.2.1.2 [TS36331]. Поддерживаемые блоки системной информации:

·

Эталонный Информация Заблокировать (МИБ)
Содержит параметры, относящиеся к уровню PHY, сгенерированные во время
конфигурации и передается каждые 10 мс в начале радиокадра в виде
контрольное сообщение.

·

Система Информация Заблокировать Тип 1 (СИБ1)
Содержит информацию о доступе к сети, передаваемую каждые 20 мс в
середина радиокадра в качестве управляющего сообщения. Не используется в ручном креплении
метод. UE должно декодировать MIB, прежде чем оно сможет принять SIB1.

·

Система Информация Заблокировать Тип 2 (СИБ2)
Содержит настройки, относящиеся к UL и RACH, запланированные для передачи по протоколу RRC.
через 16 мс после настройки ячейки, а затем повторяется каждые 80 мс (настраивается
через LteEnbRrc::SystemInformationPeriodicity атрибут. UE должен быть кемпинг
в ячейку, чтобы получить ее SIB2.

Прием системной информации имеет основополагающее значение для продвижения UE в его жизненном цикле. MIB
позволяет UE увеличить начальную полосу пропускания DL с 6 RB до фактической рабочей
пропускная способность сети. SIB1 предоставляет информацию, необходимую для выбора соты
оценка (поясняется в следующем разделе). И, наконец, SIB2 требуется до того, как UE
разрешено перейти в состояние CONNECTED.

Ячейка Выбор Оценка
RRC UE рассматривает отчет об измерениях, подготовленный в Ячейка Поиск и доступ к ячейке
информация предоставлена ​​SIB1. Как только обе информации доступны для конкретной ячейки,
UE запускает процесс оценки. Цель этого процесса состоит в том, чтобы определить, является ли
ячейка является подходящей ячейкой для лагеря.

Процесс оценки представляет собой слегка упрощенную версию раздела 5.2.3.2 [TS36304].
Он состоит из следующих критериев:

· Критерий уровня Rx; и

· Критерий закрытой группы абонентов (CSG).

Первый критерий, уровень Rx, основан на измеренном RSRP ячейки Q_{rxlevmeas}, который
должен быть выше необходимого минимума Q_{rxlevmin}, чтобы пройти критерий:

где Q_{rxlevmin} определяется каждым eNodeB и может быть получено UE от SIB1.

Последний критерий, CSG, представляет собой комбинацию параметра истинности или ложности, называемого РГС
индикация и простое число РГС личность. Основное правило заключается в том, что UE не должен
eNodeB с другим идентификатором CSG. Но это правило применяется только тогда, когда индикация CSG
оценивается как истинное. Более подробная информация представлена ​​в разделе sec-network-attachment Пользователя.
Документация.

Когда ячейка соответствует всем вышеперечисленным критериям, ячейка считается подходящее. Затем УЭ
лагеря к нему (IDLE_CAMPED_НОРМАЛЬНО штат).

После этого верхний уровень может запросить у UE переход в режим CONNECTED. Пожалуйста, обратитесь к разделу
РКР связи создание для подробностей об этом.

С другой стороны, если ячейка не соответствует критерию CSG, ячейка помечается как
as приемлемый (Раздел 10.1.1.1 [TS36300]). В этом случае объект RRC сообщит PHY
объект для синхронизации со второй самой сильной ячейкой и повторения первоначального выбора ячейки
процедура, использующая эту ячейку. Пока подходящая сота не найдена, UE будет повторять эти
шаги, избегая ячеек, которые были идентифицированы как приемлемые.

Радио Зачисление в школу Контролировать
Управление доступом к радио поддерживается за счет наличия ответа RRC eNB на RRC-СОЕДИНЕНИЕ.
Сообщение REQUEST, отправленное UE либо с сообщением RRC CONNECTION SETUP, либо с сообщением RRC.
Сообщение CONNECTION REJECT, в зависимости от того, должно ли быть допущено новое UE или нет. В
текущая реализация, поведение определяется логическим атрибутом
ns3::LteEnbRrc::AdmitRrcConnectionRequest. В настоящее время нет контроля доступа к радио
алгоритм, который динамически решает, будет ли разрешено новое соединение или нет.

Радио податель Конфигурация
Некоторые варианты реализации были сделаны в RRC в отношении настройки радиосвязи.
носители:

· три группы логических каналов (из четырех доступных) настроены для буфера восходящего канала
в целях отчета о состоянии в соответствии со следующей политикой:

· LCG 0 для сигнальных радиоканалов

· LCG 1 предназначен для однонаправленных радиоканалов данных GBR.

· LCG 2 предназначен для однонаправленных радиоканалов данных, отличных от GBR.

Радио Ссылка Ошибка
Поскольку на данном этапе RRC поддерживает только режим CONNECTED, сбой радиоканала (RLF)
не обрабатывается. Причина в том, что один из возможных исходов RLF (когда RRC
повторная установка не удалась) заключается в том, чтобы оставить RRC ПОДКЛЮЧЕННЫМ, уведомив NAS о RRC.
сбой соединения. Для правильного моделирования RLF должен поддерживаться режим RRC IDLE,
включая, в частности, (повторный) выбор соты в режиме ожидания.

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

UE РКР измерения Модель
UE РКР размеры поддержка
Объект RRC UE обеспечивает поддержку измерений UE; в частности, он реализует
процедуры, описанные в разделе 5.5 [TS36331], со следующим упрощением
предположения:

· поддерживаются только внутричастотные измерения E-UTRA, что предполагает:

· при моделировании используется только один объект измерения;

· для проведения измерений не требуются измерительные промежутки;

· События B1 и B2 не реализованы;

· Только отчет StrongestCells цель поддерживается, в то время как отчетCGI и
отчетStrongestCellsForSON цели не поддерживаются;

· s-мера не поддерживается;

· поскольку агрегация несущих не поддерживается модулем LTE, следующие
предположения в измерениях UE остаются верными:

· нет понятия вторичной ячейки (SCell);

· первичная ячейка (ПКелл) просто означает обслуживающую камеру;

· Событие А6 не реализовано;

· масштабирование времени до срабатывания в зависимости от скорости (раздел 5.5.6.2 [TS36331]) не
поддерживается.

В общем дизайн интерфейса
Модель основана на концепции UE размеры потребитель, который является сущностью, которая может
запрашивать объект RRC eNodeB для предоставления отчетов об измерениях UE. Потребители, для
пример, Сдавать алгоритм, которые вычисляют решение о передаче обслуживания на основе измерения UE
отчеты. Тестовые случаи и пользовательские программы также могут стать потребителями. Фигура Родство
между UE размеры и его потребителей изображает отношения между этими сущностями.
[изображение] Связь между измерениями UE и его потребителями. UNINDENT

Вся функция измерений UE на уровне RRC делится на 4 основные части:

1. Конфигурация измерений (управляется ЛтеУеРрк::ApplyMeasConfig)

2. Выполнение измерений (выполняется LteUeRrc::DoReportUeMeasurements)

3. Запуск отчета об измерении (обрабатывается LteUeRrc::MeasurementReportTriggering)

4. Отчет об измерениях (обрабатывается ЛтеУеРрк::Сендмереасументрепорт)

В следующих разделах будет описана каждая из вышеперечисленных частей.

Анализ эффективности конфигурация
Объект RRC eNodeB настраивает измерения UE, отправляя параметры конфигурации на
объект RRC UE. Этот набор параметров определяется в MeasConfig Информация
Элемент (IE) сообщения реконфигурации соединения RRC (РКР связи
реконфигурация).

Объект RRC eNodeB реализует параметры конфигурации и процедуры, описанные в
Раздел 5.5.2 [TS36331] со следующим упрощающим предположением:

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

· все UE, подключенные к eNodeB, будут настроены одинаково, т.е.
поддержка настройки конкретного измерения для конкретного UE; а также

· предполагается, что существует однозначное соответствие между PCI и E-UTRAN
Глобальный идентификатор соты (EGCI). Это согласуется с предположениями моделирования PCI.
описанный в UE PHY измерения Модель.

Экземпляр RRC eNodeB здесь действует как посредник между потребителями и
присоединенные UE. В начале моделирования каждый потребитель предоставляет eNodeB RRC.
экземпляр с необходимой ему конфигурацией измерений UE. После этого eNodeB
RRC распространяет конфигурацию на подключенные UE.

Пользователи могут настроить конфигурацию измерения, используя несколько методов. Пожалуйста, обратитесь к
Раздел sec-configure-ue-measurements Пользовательской документации для описания
эти методы.

Выполнение размеры
UE RRC периодически получает измерения RSRP и RSRQ от UE PHY, как
описанный в UE PHY измерения Модель. Слой 3 фильтрация будут применяться к этим
полученные измерения. Реализация фильтрации соответствует разделу 5.5.3.2
[ТС36331]:

где:

· M_n – последний полученный результат измерения с физического уровня;

· F_n – обновленный отфильтрованный результат измерения;

· F_{n-1} – это старый отфильтрованный результат измерения, где F_0 = M_1 (т.е. первый
измерение не фильтруется); а также

· a = (ac{1}{2})^{ac{k}{4}}, где k — настраиваемый фильтрКоэффициент предоставляемые
КоличествоКонфигурация;

k = 4 является значением по умолчанию, но его можно настроить, установив RsrpFilterКоэффициент и
RsrqFilterКоэффициент атрибуты в Лтеенбрррк.

Следовательно, k = 0 отключит фильтрацию уровня 3. С другой стороны, прошлые измерения могут
получить большее влияние на результаты фильтрации за счет использования большего значения k.

Анализ эффективности сообщают срабатывание
В этой части UE RRC просматривает список активных конфигураций измерений и
проверить выполнение условия срабатывания в соответствии с п. 5.5.4
[TS36331]. Когда хотя бы одно условие срабатывания из всех активных измерений
конфигурация выполнена, процедура отчета об измерении (описанная в следующем
подраздел) будет начато.

3GPP определяет два типа тип триггера: периодическое издание и событийный, На данный момент только
поддерживается критерий на основе событий. Можно выбрать различные события, которые
кратко описаны в таблице ниже:

Список of поддержал событийный срабатывание Критерии
┌─────────┬────────────────────────────────
│ Имя │ Описание │
├─────────┼────────────────────────────────
│Событие A1 │ Обслуживающая ячейка становится лучше, чем │
│ │ порог │
├─────────┼────────────────────────────────
│Событие A2 │ Обслуживающая ячейка становится хуже, чем │
│ │ порог │
├─────────┼────────────────────────────────
│Событие A3 │ Сосед становится смещение дБ │
│ │ лучше, чем обслуживающая камера │
├─────────┼────────────────────────────────
│Событие A4 │ Сосед становится лучше, чем │
│ │ порог │
└─────────┴───────────────────────────────└

│Событие A5 │ Обслуживание становится хуже, чем │
│ │ порог1 И сосед становится │
│ │ лучше, чем порог2 │
└─────────┴───────────────────────────────└

В триггере, основанном на событии, необходимо проверить два основных условия: входящий состояние и
уход состояние. Более подробную информацию об этих двух можно найти в Разделе 5.5.4
[TS36331].

Триггер на основе событий можно дополнительно настроить, введя гистерезис и
время срабатывания. Гистерезис (Hys) определяет расстояние между входом и выходом
условия в дБ. Сходным образом, время до срабатывания вводит задержку как для входа, так и для выхода
условиях, а как единицу времени.

Команда периодическое издание тип триггера отчетов не поддерживается, но его поведение можно легко
полученный с помощью триггера на основе событий. Это можно сделать, настроив измерение
таким образом, чтобы входное условие всегда выполнялось, например, путем установки
порог события А1 равен нулю (минимальный уровень). В результате отчеты об измерениях
всегда будет запускаться через каждый определенный интервал, как определено отчетИнтервал
поле внутри LteRrcSap::ReportConfigEutra, поэтому производит то же поведение, что и
периодическая отчетность.

В качестве ограничения по отношению к спецификациям 3GPP текущая модель не поддерживает
любая специфичная для ячейки конфигурация. Эти параметры конфигурации определяются в измерении
объект. Как следствие, включение списка черных ячеек в процесс запуска
не поддерживается. Более того, смещение, характерное для соты (т. е. O_{cn} и O_{cp} в событии A3, A4,
и A5) также не поддерживаются. Вместо
их.

Анализ эффективности сообщают
Эта часть обрабатывает отправку отчета об измерениях от объекта RRC UE в
обслуживающий объект eNodeB по протоколу RRC. Было принято несколько упрощающих предположений:

· отчетСумма is применимый (т.е. всегда считается бесконечным);

· в отчетах об измерениях отчетКоличество всегда предполагается, что И ТО И ДРУГОЕ, т. е. оба
RSRP и RSRQ всегда сообщаются, независимо от триггерКоличество.

Сдавать
Модель RRC поддерживает мобильность UE в режиме CONNECTED, вызывая передачу обслуживания на основе X2.
процедура. Модель является внутри-EUTRAN и внутричастотной, в соответствии с разделом 10.1.2.1
[TS36300].

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

Есть два способа инициировать процедуру хэндовера:

· эксплицитно (или вручную), запускаемый программой моделирования путем планирования
выполнение метода LteEnbRrc::Сендхандоверрекуест; или

· автоматически инициируется объектом RRC eNodeB на основе измерений UE и
в соответствии с выбранным алгоритмом передачи.

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

Сдавать алгоритм
Хэндовер в 3GPP LTE имеет следующие свойства:

·

с помощью UE
UE предоставляет входные данные в сеть в виде отчетов об измерениях. Этот
обрабатывается UE РКР измерения Модель.

·

Сетевое управление
Сеть (то есть исходный eNodeB и целевой eNodeB) решает, когда
запускает хендовер и наблюдает за его выполнением.

Команда сдавать алгоритм работает в исходном eNodeB и отвечает за передачу обслуживания
решения в «автоматическом» режиме. Он взаимодействует с экземпляром RRC eNodeB через
Сдавать Руководство SAP интерфейс. Эти отношения показаны на рисунке
Родство между UE размеры и его потребителей из предыдущего раздела.

Интерфейс алгоритма хендовера состоит из следующих методов:

·

Аддуемесрепортконфигфорхэндовер
(Алгоритм хэндовера -> RRC eNodeB) Используется алгоритмом хендовера для запроса
отчеты об измерениях от объекта RRC eNodeB, передав требуемый
конфигурация отчетности. Конфигурация будет применяться ко всем будущим
присоединенные UE.

·

СообщитьUeMeas
(eNodeB RRC -> Алгоритм передачи обслуживания) На основе настроенных измерений UE
ранее в Аддуемесрепортконфигфорхэндовер, UE может предоставлять отчеты об измерениях
к eNodeB. Объект RRC eNodeB использует СообщитьUeMeas интерфейс к
направить эти отчеты об измерениях алгоритму передачи обслуживания.

·

ТриггерХэндовер
(Алгоритм передачи обслуживания -> RRC eNodeB) После изучения отчетов об измерениях
(но не обязательно), алгоритм хэндовера может объявить хэндовер. Этот
метод используется для уведомления объекта RRC eNodeB об этом решении, которое
затем перейдите к началу процедуры передачи.

Одно замечание для Аддуемесрепортконфигфорхэндовер. Метод вернет MeasId
(идентификатор измерения) вновь созданной конфигурации измерения. Обычно
Алгоритм передачи обслуживания будет хранить этот уникальный номер. Это может быть полезно в СообщитьUeMeas
метод, например, когда было запрошено более одной конфигурации и передача
алгоритм должен различать входящие отчеты на основе конфигурации, которая
запустил их.

Алгоритм передачи обслуживания реализуется путем написания подкласса LteHandoverАлгоритм
абстрактный суперкласс и реализация каждого из вышеупомянутых методов интерфейса SAP.
Таким образом, пользователи могут разработать свой собственный алгоритм передачи обслуживания, а затем использовать его в любом моделировании.
следуя шагам, описанным в разделе sec-x2-based-handover пользователя
Документация.

Кроме того, пользователи могут использовать один из 3 встроенных алгоритмов передачи обслуживания.
по модулю LTE: отсутствие операций, A2-A4-RSRQ и алгоритм наилучшей передачи обслуживания соты. Они есть
готов к использованию в симуляциях или может быть взят в качестве примера реализации хендовера
алгоритм. Каждый из этих встроенных алгоритмов рассматривается в каждом из следующих
подразделы.

Нет операции сдавать алгоритм
Команда не оп сдавать алгоритм (Алгоритм NoOpHandover класс) является самым простым из возможных
реализация алгоритма хендовера. Он в основном ничего не делает, т.е. не вызывает никаких
методов интерфейса SAP Handover Management. Пользователи могут выбрать этот алгоритм передачи
если они хотят отключить автоматический триггер передачи обслуживания в своей симуляции.

A2-A4-RSRQ сдавать алгоритм
Команда A2-A4-RSRQ сдавать алгоритм обеспечивает функциональность хендовера по умолчанию
алгоритм, изначально включенный в LENA M6 (ns-3.18), перенесенный в SAP Handover Management
интерфейс как A2A4RsrqАлгоритм передачи класса.

Как следует из названия, алгоритм использует качество принятого опорного сигнала (RSRQ).
измерения, полученные по Событию A2 и Событию A4. Таким образом, алгоритм добавит 2
конфигурации измерения в соответствующий экземпляр RRC eNodeB. Их предполагаемое использование
описывается следующим образом:

· События A2 (RSRQ обслуживающей ячейки становится хуже, чем порог) используется для обозначения
что UE испытывает плохое качество сигнала и может извлечь выгоду из передачи обслуживания.

· События A4 (значение RSRQ соседней ячейки становится лучше, чем порог) используется для обнаружения
соседние соты и получают их соответствующие RSRQ от каждого подключенного UE, которое
затем сохраняются внутри алгоритма. По умолчанию алгоритм настраивается
Событие A4 с очень низким порогом, поэтому критерии срабатывания всегда верны.

Figure A2-A4-RSRQ сдавать алгоритм ниже кратко описана эта процедура.
[изображение] Алгоритм передачи A2-A4-RSRQ. UNINDENT

Для настройки поведения алгоритма можно установить два атрибута:

·

Порог обслуживания ячейки
Команда порог для события A2, т. е. UE должен иметь RSRQ ниже этого
порог, который следует учитывать при передаче.

·

Соседняя ЯчейкаСмещение
Команда смещение целью которого является обеспечение того, чтобы UE получало лучшее качество сигнала
после передачи. Соседняя ячейка рассматривается как целевая ячейка для
передача обслуживания только в том случае, если ее RSRQ выше, чем RSRQ обслуживающей соты на величину
этого смещение.

Значение обоих атрибутов выражается в виде диапазона RSRQ (раздел 9.1.7 [TS36133]),
которое представляет собой целое число от 0 до 34, где 0 является наименьшим значением RSRQ.

Самый сильный ячейка сдавать алгоритм
Команда сильная ячейка сдавать алгоритм, или также иногда известный как традиционный мощностью
бюджет (ПБГТ) алгоритм, разработан с использованием [Dimou2009] в качестве эталона. Идея состоит в том, чтобы
предоставить каждому UE наилучшую возможную мощность принимаемого опорного сигнала (RSRP). Это
делается путем выполнения передачи обслуживания, как только лучшая ячейка (т. е. с более сильным RSRP)
обнаружено.

События A3 (RSRP соседней соты становится лучше, чем RSRP обслуживающей соты)
реализовать эту концепцию. A3RsrpАлгоритм передачи обслуживания класс является результатом
реализация. Для UE инициируется передача обслуживания в лучшую соту в измерении.
сообщить.

Моделирование, в котором используется этот алгоритм, обычно более уязвимо для пинг-понговой передачи обслуживания.
(последовательная передача обслуживания предыдущему исходному eNodeB в течение короткого периода времени),
особенно когда Замирание Модель включен. Обычно эта проблема решается
внесение определенной задержки в передачу обслуживания. Алгоритм делает это, включая
параметры гистерезиса и времени срабатывания (раздел 6.3.5 [TS36331]) для UE
конфигурация измерений.

Гистерезис (он же маржа передачи) задерживает передачу обслуживания в отношении RSRP. Значение
выражается в дБ, находится в диапазоне от 0 до 15 дБ и имеет точность 0.5 дБ, например, входной
значение 2.7 дБ округляется до 2.5 дБ.

С другой стороны, время до срабатывания задерживает передачу по времени. 3GPP определяет 16
допустимые значения времени срабатывания (все в миллисекундах): 0, 40, 64, 80, 100, 128, 160, 256,
320, 480, 512, 640, 1024, 1280, 2560 и 5120.

Разница между гистерезисом и временем срабатывания показана на рисунке. эффект of
гистерезис и время до срабатывания in сильная ячейка сдавать алгоритм ниже, который взят
из Лена-x2-передачи-меры пример. Он отображает воспринимаемый RSRP обслуживающей ячейки.
и соседнюю соту с помощью UE, которое перемещается за границу сот.
[изображение] Влияние гистерезиса и времени срабатывания при самом сильном переключении ячеек
алгоритм.UNINDENT

По умолчанию алгоритм использует гистерезис 3.0 дБ и время срабатывания 256 мс.
Эти значения можно настроить с помощью Гистерезис и Таймтотриггер атрибуты
A3RsrpАлгоритм передачи обслуживания класса.

соседка Связь
Модуль LTE поддерживает упрощенный Автоматический соседка Связь (ANR) функция. Это
обрабатывается ЛтеАнр класс, который взаимодействует с экземпляром RRC eNodeB через ANR
САП-интерфейс.

соседка Связь Таблица
ANR имеет соседка Связь Таблица (НЗТ), аналогично описанию в разделе
22.3.2a [TS36300]. Каждая запись в таблице называется соседка Связь (NR) и
представляет обнаруженную соседнюю ячейку, которая содержит следующие логические поля:

·

Нет Удалить
Указывает, что NR должен быть удалены из НРТ. Это правда by
по умолчанию для предоставленного пользователем NR и ложный в противном случае.

·

Нет X2 Указывает, что NR должен использовать интерфейс X2, чтобы инициировать
процедуры по отношению к eNodeB, родительскому по отношению к целевой соте. Это ложный by
значение по умолчанию для предоставленного пользователем NR и правда в противном случае.

·

Нет HO Указывает, что NR должен использоваться eNodeB для целей передачи обслуживания.
Это правда в большинстве случаев, за исключением случаев, когда NR предоставляется пользователем и
обнаружена сетью.

Каждая запись NR может иметь по крайней мере одно из следующих свойств:

·

Предоставляется пользователем
Этот тип NR создается в соответствии с инструкциями пользователя моделирования. Например,
NR создается автоматически при инициированном пользователем установлении X2
соединение между 2 eNodeB, например, как описано в разделе
передача обслуживания на основе sec-x2. Другой способ создать предоставленный пользователем NR — вызвать метод
ДобавитьNeighbourRelation функционировать явно.

·

Обнаружено сетью
Этот тип NR создается автоматически во время моделирования в результате
обнаружение соседней клетки.

Для автоматического создания обнаруженного сетью NR, ANR использует измерения UE. В
Другими словами, ANR является потребителем измерений UE, как показано на рисунке. Родство
между UE размеры и его потребителей. RSRQ и Событие A4 (сосед становится лучше
чем порог) используются для настройки отчетов. Событие по умолчанию A4 порог
установлен на минимально возможный, т. е. максимальную способность обнаружения, но может быть изменен с помощью
установка порог атрибут ЛтеАнр класс. Обратите внимание, что передача обслуживания A2-A4-RSRQ
Алгоритм также использует аналогичную конфигурацию отчетов. Несмотря на сходство, когда
и ANR, и этот алгоритм хендовера активны в eNodeB, они используют отдельные отчеты
конфигурации.

Также обратите внимание, что автоматическая настройка интерфейса X2 не поддерживается. Вот почему
Нет X2 и Нет HO поля являются истинными в обнаруженном сетью, но не обнаруженном пользователем NR.

Роли of ANR in Симуляторы
Интерфейс SAP ANR обеспечивает средства связи между ANR и RRC eNodeB. Немного
функции интерфейса используются eNodeB RRC для взаимодействия с NRT, как показано ниже:

·

ДобавитьNeighbourRelation
(eNodeB RRC -> ANR) Добавить новую запись NR, предоставленную пользователем, в NRT.

·

GetNoRemove
(eNodeB RRC -> ANR) Получите значение Нет Удалить поле записи NR
заданный идентификатор ячейки.

·

GetNoHo
(eNodeB RRC -> ANR) Получите значение Нет HO поле записи NR данного
идентификатор ячейки.

·

ПолучитьNoX2
(eNodeB RRC -> ANR) Получите значение Нет X2 поле записи NR данного
идентификатор ячейки.

Существуют и другие интерфейсные функции для поддержки роли ANR в качестве потребителя измерений UE,
как указано ниже:

·

АддУеМеасрепортконфигфоранр
(ANR -> eNodeB RRC) Используется ANR для запроса отчетов об измерениях от
Объект RRC eNodeB, передав требуемую конфигурацию отчетности.
конфигурация будет применяться ко всем будущим подключенным UE.

·

СообщитьUeMeas
(eNodeB RRC -> ANR) На основе измерений UE, настроенных ранее в
АддУеМеасрепортконфигфоранрUE может отправлять отчеты об измерениях на eNodeB.
Объект RRC eNodeB использует СообщитьUeMeas интерфейс для пересылки этих
отчеты об измерениях в ANR.

Пожалуйста, обратитесь к соответствующей документации API для ЛтеАнрСап класс для более подробной информации
об использовании и требуемых параметрах.

ANR используется экземпляром RRC eNodeB в качестве структуры данных для отслеживания
положение близлежащих соседних ячеек. ANR также помогает экземпляру RRC eNodeB
определить, возможно ли выполнить процедуру передачи обслуживания в соседнюю соту.
Это реализуется тем фактом, что RRC eNodeB разрешает только процедуру передачи обслуживания.
произойдет, если запись NR целевой ячейки имеет оба Нет HO и Нет X2 поля установлены на ложный.

ANR включен по умолчанию в каждом экземпляре eNodeB в моделировании. Его можно отключить
установив АнрВключено атрибут в LteHelper класс к ложный.

РКР последовательность диаграммы
В этом разделе мы приводим несколько диаграмм последовательности, которые объясняют наиболее важные RRC.
моделируемые процедуры.

РКР связи создание
Figure Последовательность диаграмма of РКР Связь Разработчик процедуры показывает, как RRC
Процедура установления соединения смоделирована с выделением роли уровня RRC на
как UE, так и eNB, а также взаимодействие с другими уровнями.
[изображение] Диаграмма последовательности процедуры установления соединения RRC. UNINDENT

Существует несколько тайм-аутов, связанных с этой процедурой, которые перечислены ниже.
Таблица Таймеры in РКР связи создание процедуры . Если срок действия любого из этих таймеров истек,
процедура установления RRC-соединения завершается с ошибкой. В этом случае
верхний уровень (UE NAS) немедленно попытается повторить процедуру, пока она не завершится
успешно.

Таймеры in РКР связи создание процедуры
┌ackindyacsideabults ─────────────┬──────────┬────────────────┐
│Имя │ Местоположение │ Запуск таймера │ Останов таймера │ По умолчанию │ Когда таймер │
│ │ │ │ │ продолжительность │ истек │
├ackindyacsideabults ─────────────┼──────────┼────────────────┤
│Соединение │ eNodeB RRC │ Новый контекст UE │ Получение RRC │ 15 мс │ Удаление UE │
│запрос │ │ добавлено │ ПОДКЛЮЧЕНИЕ │ │ контекст │
│таймаут │ │ │ ЗАПРОС │ │ │
├ackindyacsideabults ─────────────┼──────────┼────────────────┤
│Соединение │ UE RRC │ Отправка RRC │ Получение RRC │ 100 мс │ Сброс UE MAC │
│тайм-аут (T300 │ │ СОЕДИНЕНИЕ │ СОЕДИНЕНИЕ │ │ │
│таймер) │ │ ЗАПРОС │ НАСТРОЙКА или │ │ │
│ │ │ │ ОТКЛОНИТЬ │ │ │
├ackindyacsideabults ─────────────┼──────────┼────────────────┤
│Соединение │ eNodeB RRC │ Отправить RRC │ Принять RRC │ 100 мс │ Удалить UE │
│тайм-аут установки │ │ СОЕДИНЕНИЕ │ СОЕДИНЕНИЕ │ │ контекст │
│ │ │ НАСТРОЙКА │ НАСТРОЙКА ЗАВЕРШЕНА │ │ │
├ackindyacsideabults ─────────────┼──────────┼────────────────┤
│Соединение │ eNodeB RRC │ Отправить RRC │ Никогда │ 30 мс │ Удалить UE │
│отклонено │ │ СОЕДИНЕНИЕ │ │ │ контекст │
│тайм-аут │ │ ОТКЛОНИТЬ │ │ │ │
└ackindyacsideabults ─────────────┴──────────┴─────────────────

РКР связи реконфигурация
Figure Последовательность диаграмма of РКР Связь реконфигурация процедуры показывает, как RRC
Процедура перенастройки соединения смоделирована для случая, когда MobilityControlInfo
не предусмотрено, т. е. хендовер не выполняется.
[изображение] Схема последовательности процедуры реконфигурации соединения RRC. UNINDENT

Figure Последовательность диаграмма of РКР Связь реконфигурация процедуры для сдавать
, признали показывает, как процедура реконфигурации соединения RRC моделируется для случая
где предоставляется MobilityControlInfo, т. е. должна быть выполнена передача обслуживания. Как указано
в [TS36331], После получение сдавать сообщение, UE попытки в доступ цель
ячейка at первый доступен КСД раз согласно в Случайно О компании ресурс выбор
определенный in [ТС36321]_, т.е. сдавать is асинхронный. Следовательно, когда выделение
a преданный преамбула для случайный доступ in цель клетка, Э-УТРА должен обеспечивать it is
доступен от первый КСД раз UE май использовать. на успешный завершение of
сдавать, UE посылает a сообщение использовал в подтвердить сдавать. Обратите внимание, что случайный
процедура доступа в этом случае неконфликтная, поэтому в реальной системе LTE она
незначительно отличается от используемого при установлении RRC-соединения. Также обратите внимание, что РА
Идентификатор преамбулы сообщается через команду передачи обслуживания, включенную в запрос передачи обслуживания X2.
сообщение ACK, отправленное из целевого eNB в исходный eNB; в частности, преамбула
включены в RACH-ConfigDedicated IE, который является частью MobilityControlInfo.
[изображение] Диаграмма последовательности процедуры реконфигурации соединения RRC для
случай передачи.UNINDENT

РКР протокол ухода
Как и предполагалось ранее, мы предлагаем две разные модели трансмиссии и
прием сообщений RRC: Ideal и Real. Каждый из них описан в одном из
следующие подразделы.

Ideal РКР протокол модель
По этой модели, реализованной в классах и LteUeRrcProtocolIdeal и
LteEnbrRrcПротоколИдеал, все сообщения RRC и информационные элементы передаются между
eNB и UE идеальным образом, без потребления радиоресурсов и без
ошибки. С точки зрения реализации это достигается передачей данных RRC
структура непосредственно между RRC-объектами UE и eNB, без вовлечения нижних уровней
(PDCP, RLC, MAC, планировщик).

Real РКР протокол модель
Эта модель реализована в классах LteUeRrcПротоколРеал и LteEnbrRrcПротоколРеал
и направлен на моделирование передачи PDU RRC, как это обычно происходит в реальном LTE.
системы. Особенно:

· для каждого отправляемого сообщения RRC создаются реальные PDU RRC в соответствии с ASN.1.
кодирование PDU RRC и информационных элементов (IE), указанных в [TS36331]. Некоторый
в отношении IE, включенных в PDU, сделаны упрощения, т.е.
Включены IE, полезные для целей моделирования. Подробный список, пожалуйста
см. IE, определенные в lte-rrc-sap.h и сравните с [TS36331].

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

Сигнализация Радио податель модель
Теперь мы опишем модель Signaling Radio Bearer, которая используется для Real протокол RRC
модели.

· SRB0 сообщения (через CCCH):

· Рркконнектионрекуест: в реальных системах LTE это SDU RLC TM, отправленный
ресурсы, указанные в UL Grant в RAR (не в UL DCI); причина в том, что
На данном этапе C-RNTI еще не известен. В симуляторе это моделируется как реальная
RLC TM RLC PDU, чьи ресурсы UL выделяются планировщиком при вызове
SCHED_DL_RACH_INFO_REQ.

· Рркконнектионсетап: в симуляторе это реализовано как в реальных системах LTE,
т. е. с SDU RLC TM, отправленным по ресурсам, обозначенным обычным UL DCI,
выделено с помощью SCHED_DL_RLC_BUFFER_REQ, инициированного экземпляром RLC TM, который
сопоставляется с LCID 0 (CCCH).

· SRB1 сообщения (через DCCH):

· Все сообщения SRB1, смоделированные в симуляторе (например, РркСоединениеЗавершено) находятся
реализовано как в реальных системах LTE, т. е. с реальным SDU RLC, отправленным через RLC AM
используя ресурсы DL, выделенные через отчеты о состоянии буфера. Посмотреть модель RLC
документация для деталей.

· SRB2 сообщения (через DCCH):

· Согласно [TS36331], "SRB1 is для РКР Сообщения (который май включают a
спекулировали NAS сообщение) as хорошо as для NAS Сообщения предшествующий в создание
of СРБ2, ВСЕ через DCCH логический канал", тогда как "SRB2 is для NAS Сообщения,
через DCCH логический канал, а такжеSRB2 и a низкоприоритетный чем SRB1 и is
всегда настроить by Е-UTRAN после безопасность что он активирует"Моделирование
аспекты, связанные с безопасностью, не являются требованием имитационной модели LTE,
поэтому мы всегда используем SRB1 и никогда не активируем SRB2.

ASN.1 кодирование of РКР IE
Сообщения, определенные в RRC SAP, общие для всех пользователей/поставщиков SAP Ue/Enb, транспортируются
в прозрачном контейнере в/из Ue/Enb. Формат кодирования для разных
Информационные элементы указаны в [TS36331] с использованием правил ASN.1 в невыровненном
вариант. Реализация в Ns3/Lte разделена на следующие классы:

· Asn1Header: Содержит кодирование/декодирование основных типов ASN.

· RrcAsn1Header: наследует Asn1Header и содержит кодировку/декодирование общих
IE определен в [TS36331]

· Классы специальных сообщений/IE RRC: класс для каждого из сообщений, определенных в RRC.
Заголовок SAP

Asn1Заголовок класс - Реализация of Использование темпера с изогнутым основанием ASN.1 Типы
Этот класс реализует методы для сериализации/десериализации типов ASN.1, используемых в
[TS36331], в соответствии с правилами упакованного кодирования в ITU-T X.691. Рассматриваемые типы
составляют:

· Boolean: логическое значение использует один бит (1=истина, 0=ложь).

· Целое число: ограниченное целое число (с заданными минимальными и максимальными значениями) использует минимальное
количество битов для кодирования его диапазона (max-min+1).

· Bitstring: бистрока будет копироваться побитно в буфер сериализации.

· Строка октетов: в настоящее время не используется.

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

· Sequence...Of : тип последовательности...of кодирует количество элементов последовательности
как целое число (последующие элементы должны быть закодированы впоследствии).

· Choice : указывает, какой элемент среди элементов в наборе выбора кодируется.

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

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

Класс наследуется от ns-3 Header, но функция Deserialize() объявлена ​​чисто виртуальной,
таким образом, унаследованные классы должны его реализовать. Причина в том, что десериализация
извлекать элементы в сообщениях RRC, каждый из которых содержит различную информацию
элементов.

Кроме того, следует отметить, что результирующая длина байта определенного типа/сообщения
может варьироваться в зависимости от наличия необязательных полей и оптимизированной кодировки.
Следовательно, сериализованные биты будут обрабатываться с помощью функции PreSerialize(), сохраняя
результат в буфере m_serializationResult. Поскольку методы чтения/записи в буфер ns3
определено в байтах, биты сериализации сохраняются в m_serializationPendingBits
атрибут, пока не будут установлены 8 бит, и их можно будет записать в итератор буфера. Наконец, когда
вызывая Serialize(), содержимое атрибута m_serializationResult будет скопировано
в параметр Buffer::Iterator

РркАсн1Заголовок : Общий IE
Поскольку некоторые информационные элементы используются для нескольких сообщений RRC, этот класс
реализует следующие распространенные IE:

· Србтоаддмодлист

· Дрбтоаддмодлистист

· Конфигурация логического канала

· RadioResourceConfigDedicated

· Физическая конфигурация

· СистемнаяИнформацияБлокТип1

· СистемнаяИнформацияБлокТип2

· RadioResourceConfigCommonSIB

RRC конкретный сообщения/IE классов
Были реализованы следующие RRC SAP:

· Рркконнектионрекуест

· Настройка РркСоединения

· Рркконнектионсетупкомплетед

· РркСоединениеРеконфигурация

· RrcConnectionReconfigurationCompleted

· Информация о подготовке к передаче

· RrcConnectionReinstallationRequest

· RrcConnectionReinstallation

· RrcConnectionReinstallationComplete

· RrcConnectionReinstallationReject

· Рркконнектионрелиз

NAS
В центре внимания модели LTE-EPC находится активное состояние NAS, которое соответствует EMM.
Зарегистрирован, ECM подключен, RRC подключен. Из-за этого следующие
сделаны упрощения:

· EMM и ECM явно не моделируются; вместо этого объект NAS в UE будет
взаимодействовать непосредственно с MME для выполнения действий, которые эквивалентны (с грубым
упрощения) для перевода UE в состояния EMM Connected и ECM Connected;

· NAS также заботится о мультиплексировании пакетов данных восходящего канала, поступающих с верхнего
слоев в соответствующий носитель EPS с помощью классификатора шаблона потока трафика
(ТфтКлассификатор).

· NAS не поддерживает выбор PLMN и CSG

· NAS не поддерживает процедуры обновления местоположения/пейджинга в режиме ожидания

Figure Последовательность диаграмма of прикреплять процедуры показывает, как упрощенная модель NAS
реализует процедуру присоединения. Обратите внимание, что как стандартная, так и возможная выделенная EPS
носители активируются как часть этой процедуры.
[изображение] Схема последовательности процедуры подключения. UNINDENT

S1
С1-У
Интерфейс S1-U реалистично моделируется путем инкапсуляции пакетов данных через
GTP/UDP/IP, как это делается в реальных системах LTE-EPC. Соответствующий стек протоколов показан на
Figure LTE-EPC данным самолет протокол стек. Как показано на рисунке, есть два разных
уровни IP-сетей. Первый — это сквозной уровень, который обеспечивает сквозное
подключение к пользователям; этот уровень включает в себя UE, PGW и удаленный хост
(включая возможные интернет-маршрутизаторы и хосты между ними), но не включает eNB.
По умолчанию UE назначается общедоступный IPv4-адрес в сети 7.0.0.0/8, а PGW
получает адрес 7.0.0.1, который используется всеми UE в качестве шлюза для выхода в Интернет.

Второй уровень IP-сетей — это локальная сеть EPC. Это касается всех eNB
узлы и узел SGW/PGW. Эта сеть реализована в виде набора двухточечных связей.
которые соединяют каждый eNB с узлом SGW/PGW; таким образом, SGW/PGW имеет набор
двухточечные устройства, каждое из которых обеспечивает возможность подключения к другому eNB. По умолчанию
Подсеть 10.xyz/30 назначается каждому каналу «точка-точка» (подсеть /30 — наименьшая
подсеть, допускающая использование двух разных адресов узлов).

Как указано в 3GPP, сквозная IP-связь туннелируется через локальный IP-адрес EPC.
сеть с использованием GTP/UDP/IP. Далее мы объясним, как реализовано это туннелирование.
в модели ЭПК. Объяснение делается путем обсуждения сквозного потока данных.
пакеты.
[изображение] Поток данных в нисходящем канале между Интернетом и UE. UNINDENT

Для начала рассмотрим случай нисходящего канала, который изображен на рис. Данные
поток in нисходящей линии связи между интернет и UE. Пакеты IPv4 нисходящего канала
генерируется с общего удаленного хоста и адресуется одному из устройств UE. Интернет
Маршрутизация позаботится о пересылке пакета на общее NetDevice SGW/PGW.
узел, подключенный к Интернету (это интерфейс Gi в соответствии с 3GPP
терминология). SGW/PGW имеет VirtualNetDevice, которому назначен IP-адрес шлюза.
адрес подсети UE; следовательно, статические правила маршрутизации приведут к тому, что входящий пакет
из Интернета для маршрутизации через это VirtualNetDevice. Такое устройство запускает
Процедура туннелирования GTP/UDP/IP путем пересылки пакета в специальное приложение в
узел SGW/PGW, который называется EpcSgwPgwApplication. Это приложение делает
следующие операции:

1. он определяет узел eNB, к которому подключено UE, просматривая IP-адрес
адрес назначения (который является адресом UE);

2. классифицирует пакет с помощью шаблонов потока трафика (TFT), чтобы определить, к какому
EPS Предъявитель это принадлежит. Несущие каналы EPS имеют однозначное сопоставление с несущими каналами S1-U, поэтому
эта операция возвращает идентификатор конечной точки туннеля GTP-U (TEID), к которому
пакет принадлежит;

3. добавляет в пакет заголовок соответствующего протокола GTP-U;

4. наконец, он отправляет пакет через сокет UDP в S1-U точка-точка
NetDevice, адресованное eNB, к которому подключено UE.

Как следствие, сквозной IP-пакет с недавно добавленными заголовками IP, UDP и GTP
отправляется через одну из ссылок S1 в eNB, где он принимается и доставляется локально
(поскольку адрес назначения самого удаленного IP-заголовка совпадает с IP-адресом eNB).
локальный процесс доставки перенаправит пакет через сокет UDP в выделенный
приложение под названием EpcEnbApplication. Затем это приложение выполняет следующие
операции:

1. удаляет заголовок GTP и извлекает содержащийся в нем TEID;

2. использование взаимно однозначного отображения между однонаправленными каналами S1-U и однонаправленными радиоканалами (которые
является требованием 3GPP), он определяет идентификатор носителя (BID), которому передается пакет.
принадлежит;

3. он записывает BID в специальный тег EpsBearerTag, который добавляется в
пакет;

4. он пересылает пакет на LteEnbNetDevice узла eNB через необработанный пакет.
гнездо

Обратите внимание, что в этот момент крайним заголовком пакета является сквозной IP-заголовок,
поскольку заголовки IP/UDP/GTP стека протоколов S1 уже удалены. На
приема пакета от EpcEnbApplication, LteEnbNetDevice получит
BID из EpsBearerTag и на основе BID определит экземпляр Radio Bearer.
(и соответствующие экземпляры протоколов PDCP и RLC), которые затем используются для пересылки
пакет к UE через радиоинтерфейс LTE. Наконец, LteUeNetDevice UE будет
получить пакет и доставить его локально в стек IP-протокола, который, в свою очередь,
доставить его к приложению UE, которое является конечной точкой нисходящей линии связи
связи.
[изображение] Поток данных в восходящей линии связи между UE и Интернетом. UNINDENT

Случай восходящей линии связи изображен на рисунке Данные поток in восходящей между UE и
интернет. IP-пакеты восходящей линии связи генерируются общим приложением внутри UE,
и направляется локальным стеком TCP/IP на LteUeNetDevice UE.
Затем LteUeNetDevice выполняет следующие операции:

1. классифицирует пакет с помощью TFT и определяет однонаправленный радиоканал, к которому
пакет принадлежит (и соответствующий RBID);

2. он идентифицирует соответствующий экземпляр протокола PDCP, который является точкой входа
стек радиопротокола LTE для этого пакета;

3. он отправляет пакет в eNB через стек радиопротокола LTE.

eNB принимает пакет через свое LteEnbNetDevice. Так как есть один PDCP и RLC
экземпляр протокола для каждого радиоканала, LteEnbNetDevice может определить BID
пакета. Затем этот BID записывается в EpsBearerTag, который добавляется в
пакет. Затем LteEnbNetDevice пересылает пакет в EpcEnbApplication через необработанный
пакетный сокет.

Получив пакет, EpcEnbApplication выполняет следующие операции:

1. он извлекает BID из EpsBearerTag в пакете;

2. он определяет соответствующий экземпляр носителя EPS и TEID GTP-U, используя
однозначное сопоставление между однонаправленными каналами S1-U и однонаправленными радиоканалами;

3. добавляет в пакет заголовок GTP-U, включая ранее определенный TEID;

4. он отправляет пакет на узел SGW/PGW через сокет UDP, подключенный к S1-U.
сетевое устройство «точка-точка».

На этом этапе пакет содержит заголовки S1-U IP, UDP и GTP в дополнение к
оригинальный сквозной IP-заголовок. Когда пакет получен соответствующим S1-U
точка-точка NetDevice узла SGW/PGW, доставляется локально (как пункт назначения
адрес самого внешнего IP-заголовка совпадает с адресом сетевого устройства «точка-точка»).
Процесс локальной доставки перенаправит пакет в приложение EpcSgwPgwApplication через
соответствующий сокет UDP. Затем EpcSgwPgwApplication удаляет заголовок GTP и пересылает
пакет на VirtualNetDevice. В этот момент самым внешним заголовком пакета является
сквозной IP-заголовок. Следовательно, если адрес назначения в этом заголовке является удаленным
хост в Интернете, пакет отправляется в Интернет через соответствующий NetDevice
SGW/PGW. В случае, если пакет адресован другому UE, IP-стек
SGW/PGW снова перенаправит пакет на VirtualNetDevice, и пакет будет отправлен
через процесс доставки по нисходящей линии связи, чтобы достичь своего UE назначения.

Обратите внимание, что QoS носителя EPS не применяется на каналах S1-U, предполагается, что
избыточного предоставления пропускной способности канала достаточно для удовлетворения требований QoS всех
носители.

С1АП
Интерфейс S1-AP обеспечивает взаимодействие уровня управления между eNB и MME. в
симулятор, этот интерфейс смоделирован идеально, с прямым взаимодействием между
объекты eNB и MME без фактической реализации кодирования сообщений S1AP
и информационные элементы, указанные в [TS36413], и без фактической передачи какого-либо PDU
по любой ссылке.

Смоделированные примитивы S1-AP:

· НАЧАЛЬНОЕ СООБЩЕНИЕ UE

· НАЧАЛЬНЫЙ ЗАПРОС НАСТРОЙКИ КОНТЕКСТА

· ОТВЕТ НА НАЧАЛЬНУЮ КОНТЕКСТНУЮ УСТАНОВКУ

· ЗАПРОС ПЕРЕКЛЮЧЕНИЯ ПУТИ

· ПОДТВЕРЖДЕНИЕ ЗАПРОСА ПЕРЕКЛЮЧАТЕЛЯ ПУТИ

X2
Интерфейс X2 соединяет два eNB [TS36420]. С логической точки зрения, X2
Интерфейс представляет собой двухточечный интерфейс между двумя eNB. В реальной E-UTRAN
логический интерфейс «точка-точка» должен быть возможен даже при отсутствии физического
прямое соединение между двумя eNB. В модели X2, реализованной в симуляторе,
Интерфейс X2 представляет собой двухточечную связь между двумя eNB. Устройство «точка-точка» — это
созданные в обоих eNB, и два устройства «точка-точка» подключены к сети «точка-точка».
ссылку.

Для представления того, как интерфейс X2 вписывается в общую архитектуру LENA.
имитационная модель, читатель отсылается к рисунку Обзор of LTE-EPC моделирование
модель.

Интерфейс X2, реализованный в симуляторе, обеспечивает детальную реализацию
следующие элементарные процедуры функциональности Mobility Management [TS36423]:

· Процедура запроса передачи

· Процедура подтверждения запроса на передачу обслуживания

· Процедура передачи статуса SN

· Процедура освобождения контекста UE

Эти процедуры участвуют в передаче обслуживания на основе X2. Вы можете найти подробную
описание передачи в разделе 10.1.2.1 [TS36300]. Отметим, что симулятор
модель в настоящее время поддерживает только бесшовные сдавать как определено в Разделе 2.6.3.1
[Сезия2009]; особенно, без потерь сдавать как описано в Разделе 2.6.3.2
[Sesia2009] не поддерживается на момент написания этой статьи.

Figure Последовательность диаграмма of на основе X2 сдавать ниже показано взаимодействие
сущности модели X2 в симуляторе. Заштрихованными метками отмечены моменты, когда
UE или eNodeB переходят в другое состояние RRC.
[изображение] Схема последовательности передачи обслуживания на основе X2. UNINDENT

На рисунке также показаны два таймера в рамках процедуры передачи обслуживания: сдавать уход
таймер поддерживается исходным eNodeB, в то время как сдавать присоединение таймер по цели
eNodeB. Длительность таймеров можно настроить в
ХэндоверLeavingTimeoutDuration и HandoverJoiningTimeoutDuration атрибуты
те Лтеенбрррк экземпляры. Когда один из этих таймеров истечет, процедура передачи обслуживания
считается несостоявшимся.

Однако в текущей версии LTE нет надлежащей обработки сбоя передачи обслуживания.
модуль. Пользователи должны правильно настроить симуляцию, чтобы избежать сбоя передачи.
в противном случае может произойти неожиданное поведение. Пожалуйста, обратитесь к разделу
sec-tuning-handover-simulation пользовательской документации для некоторых советов по этому поводу
вопрос.

Модель X2 — это объект, который использует услуги от:

· интерфейсы X2,

· Они реализованы как сокеты поверх устройств точка-точка.

· Они используются для отправки/получения сообщений X2 через интерфейсы X2-C и X2-U.
(т. е. двухточечное устройство, подключенное к двухточечной линии связи) в направлении
одноранговый eNB.

· приложение S1.

· В настоящее время это EpcEnbApplication.

· Используется для получения некоторой информации, необходимой для элементарных процедур X2.
сообщений.

и предоставляет услуги:

· объект RRC (X2 SAP)

· отправлять/принимать RRC-сообщения. Объект X2 отправляет сообщение RRC как прозрачное
контейнер в сообщении X2. Это сообщение RRC отправляется на UE.

Figure Реализация Модель of X2 организация и SAP показывает имплементационную модель X2
объект и его отношения со всеми другими объектами и службами в протоколе
стек.
[изображение] Модель реализации сущности X2 и SAPs.UNINDENT

Объект RRC управляет инициированием процедуры передачи обслуживания. Это делается в
Подмодуль управления передачей обслуживания объекта RRC eNB. Целевой eNB может выполнять некоторые
Процедуры входного контроля. Это делается в подмодуле «Контроль доступа».
Первоначально этот подмодуль будет принимать любой запрос на передачу обслуживания.

X2 интерфейсы
Модель X2 содержит два интерфейса:

· интерфейс X2-C. Это интерфейс управления, который используется для отправки PDU X2-AP.
(т.е. элементарные процедуры).

· интерфейс X2-U. Он используется для отправки данных носителя, когда есть DL пересылка.

Figure X2 интерфейс протокол стеки показывает стеки протоколов интерфейса X2-U и
Интерфейс X2-C, смоделированный в симуляторе.
[изображение] Стеки протоколов интерфейса X2. UNINDENT

Х2-С
Интерфейс X2-C является управляющей частью интерфейса X2 и используется для отправки
X2-AP PDU (т. е. элементарные процедуры).

В исходном стеке протоколов уровня управления интерфейсом X2 SCTP используется в качестве транспортного
протокол, но в настоящее время протокол SCTP не моделируется в симуляторе ns-3 и его
реализация выходит за рамки проекта. В качестве дейтаграммы используется протокол UDP.
ориентированный протокол вместо протокола SCTP.

Х2-У
Интерфейс X2-U используется для отправки данных несущей при наличии DL пересылка во время
выполнение процедуры хэндовера на основе X2. Аналогично тому, что сделано для С1-У
интерфейс, пакеты данных инкапсулируются через GTP/UDP/IP при отправке через этот
интерфейс. Обратите внимание, что QoS EPS-носителя не применяется на каналах X2-U, предполагается, что
что избыточного выделения пропускной способности канала достаточно для удовлетворения требований QoS.
всех носителей.

X2 Услуга Интерфейс
Интерфейс службы X2 используется объектом RRC для отправки и получения сообщений X2.
процедуры. Он разделен на две части:

· В EpcX2SapProvider часть предоставляется объектом X2 и используется объектом RRC и

· В EpcX2SapUser часть предоставляется объектом RRC и используется объектом RRC.

Примитивы, поддерживаемые нашей моделью X2-C, описаны ниже.
подразделы.

Х2-С примитивы для сдавать казнь
Для передачи обслуживания на основе X2 используются следующие примитивы:

· ЗАЯВКА НА ПЕРЕДАЧУ

· ПОДТВЕРЖДЕНИЕ ЗАПРОСА НА ПЕРЕДАЧУ

· НЕУДАЧА ПОДГОТОВКИ К ПЕРЕДАЧЕ

· ПЕРЕДАЧА СТАТУСА SN

· ВЫПУСК КОНТЕКСТА UE

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

Х2-С ЕСТЬ примитивы
Следующие примитивы можно использовать для реализации самоорганизующейся сети (SON).
функциональные возможности:

· ИНФОРМАЦИЯ О ЗАГРУЗКЕ

· ОБНОВЛЕНИЕ СТАТУСА РЕСУРСОВ

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

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

станд::вектор
m_currentUlInterferenceOverloadIndictionList;
станд::вектор
m_currentUlHighInterferenceInformationList;
EpcX2Sap::RelativeNarrowbandTxBand m_currentRelativeNarrowbandTxBand;

для подробного описания типа этих переменных мы предлагаем обратиться к файлу
epc-x2-sap.h, соответствующую документацию doxygen и содержащиеся в ней ссылки на
соответствующие разделы 3GPP TS 36.423. Теперь предположим, что во время выполнения эти переменные имеют
были установлены значимые значения в соответствии с только что упомянутыми спецификациями. Тогда ты можешь
добавьте следующий код в реализацию класса LteEnbRrc, чтобы отправить нагрузку
информационный примитив:

EpcX2Sap::CellInformationItem cii;
cii.sourceCellId = m_cellId;
cii.ulInterferenceOverloadIndictionList = m_currentUlInterferenceOverloadIndictionList;
cii.ulHighInterferenceInformationList = m_currentUlHighInterferenceInformationList;
cii.relativeNarrowbandTxBand = m_currentRelativeNarrowbandTxBand;

параметры EpcX2Sap::LoadInformationParams;
params.targetCellId = идентификатор ячейки;
params.cellInformationList.push_back (cii);
m_x2SapProvider->SendLoadInformation (параметры);

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

В следующем втором примере показано, как используется примитив обновления статуса ресурса.
Мы предполагаем, что LteEnbRrc был изменен, чтобы включить следующий новый член
переменная:

EpcX2Sap::CellMeasurementResultItem m_cmri;

аналогично предыдущему, мы ссылаемся на epc-x2-sap.h и ссылки в нем для подробного
информация об этом типе переменной. Опять же, мы предполагаем, что переменная уже была
установить значимое значение. Затем вы можете добавить следующий код, чтобы отправить
обновление статуса ресурса:

параметры EpcX2Sap::ResourceStatusUpdateParams;
params.targetCellId = идентификатор ячейки;
params.cellMeasurementResultList.push_back (m_cmri);
m_x2SapProvider->SendResourceStatusUpdate (параметры);

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

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

Не поддерживается примитивы
Примитивы оптимизации надежности мобильности, такие как индикация отказа радиоканала и
На данном этапе отчет о передаче не поддерживается.

S11
Интерфейс S11 обеспечивает взаимодействие уровня управления между SGW и MME с использованием
Протокол GTPv2-C, указанный в [TS29274]. В симуляторе этот интерфейс моделируется в
идеальная мода, с непосредственным взаимодействием между SGW и объектами MME, без
фактически реализуя кодирование сообщений и фактически не передавая
PDU по любой ссылке.

Смоделированные примитивы S11:

· СОЗДАТЬ ЗАПРОС НА СЕАНС

· СОЗДАТЬ СЕССИЙ ОТВЕТ

· ИЗМЕНИТЬ ЗАПРОС НА НОСИТЕЛЯ

· ИЗМЕНИТЬ ОТВЕТ НА НОСИТЕЛЯ

Из этих примитивов первые два используются при первоначальном подключении UE для
установление несущих S1-U; два других используются во время хендовера для переключения
Несущие каналы S1-U от исходного eNB к целевому eNB в результате приема
MME сообщения PATH SWITCH REQUEST S1-AP.

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

Downlink Запитан Контролировать
Поскольку некоторые алгоритмы повторного использования частоты требуют управления мощностью нисходящей линии связи, эта функция была отключена.
также реализовано в ns-3.
[изображение] Диаграмма последовательности управления мощностью нисходящего канала. UNINDENT

Figure Последовательность диаграмма of Downlink Запитан Контролировать показана схема последовательности настройки
значение P_A нисходящей линии связи для UE, выделяя взаимодействие между RRC и другим
сущности. Алгоритм FR инициирует RRC для изменения значений P_A для UE. Затем начинается RRC.
Функция RrcConnectionReconfiguration для информирования UE о новой конфигурации. После
успешной RrcConnectionReconfiguration, RRC может установить значение P_A для UE, вызвав
функция SetPa из CphySap, значение сохраняется в новой карте m_paMap, которая содержит значения P_A
для каждого UE, обслуживаемого eNb.

Когда LteEnbPhy запускает новый подкадр, управляющие сообщения DCI обрабатываются для получения вектора
б/у РБ. Теперь также функция GeneratePowerAllocationMap(uint16_t rnti, int rbId)
называется. Эта функция проверяет значение P_A для UE, генерирует мощность для каждого RB и сохраняет ее в
m_dlPowerAllocationMap. Затем эта карта используется
Функция CreateTxPowerSpectralDensityWithPowerAllocation для создания Ptr
txPsd.

PdschConfigDedicated (TS 36.331, 6.3.2 PDSCH-Config) был добавлен в
Структура LteRrcSap::PhysicalConfigDedicated, используемая в RrcConnectionReconfiguration.
процесса.

Хакеры: Запитан Контролировать
Управление мощностью восходящей линии связи управляет мощностью передачи различных физических каналов восходящей линии связи.
каналы. Эта функциональность описана в 3GPP TS 36.213, раздел 5.

Управление мощностью восходящего канала включено по умолчанию и может быть отключено системой атрибутов:

Config::SetDefault("ns3::LteUePhy::EnableUplinkPowerControl", BooleanValue (false));

Реализовано два механизма управления мощностью восходящего канала:

· Управление мощностью восходящего канала без обратной связи: мощность передачи UE зависит от оценки
потеря пути нисходящего канала и конфигурация канала

· Управление мощностью восходящего канала с обратной связью: как и в случае с разомкнутой петлей, кроме того, eNB может управлять UE.
мощность передачи с помощью явных команд TPC управления мощностью передачи
передается по нисходящему каналу.

Для переключения между этими двумя типами механизмов необходимо изменить параметр:

Config::SetDefault("ns3::LteUePowerControl::ClosedLoop", BooleanValue (true));

По умолчанию управление мощностью с обратной связью включено.

Две Режимы of закрыто Петля Хакеры: Запитан Контролировать доступны:

· Абсолютный режим: TxPower вычисляется с использованием абсолютных значений TPC.

· Накопительный режим: TxPower вычисляется с накопленными значениями TPC.

Для переключения между этими двумя режимами необходимо изменить параметр:

Config::SetDefault("ns3::LteUePowerControl::AccumulationEnabled", BooleanValue (true));

По умолчанию режим накопления включен, а команды TPC в DL-DCI установлены всеми
планировщики на 1, что сопоставляется со значением 0 в режиме накопления.

Хакеры: Запитан Контролировать для ПУШ
Настройка мощности передачи UE для физического совместно используемого канала восходящей линии связи (PUSCH)
передача определяется следующим образом:

· Если UE передает PUSCH без одновременного PUCCH для обслуживающей соты c, тогда
мощность передачи UE P_{PUSCH,c}(i) для передачи PUSCH в подкадре i для
обслуживающая ячейка c определяется по формуле:

· Если UE передает PUSCH одновременно с PUCCH для обслуживающей соты c, то UE
мощность передачи P_{PUSCH,c}(i) для передачи PUSCH в подкадре i для
обслуживающая ячейка c определяется по формуле:

Поскольку управление мощностью восходящей линии связи для PUCCH не реализовано, этот случай не реализован.
так же.

· Если UE не передает PUSCH для обслуживающей соты c, для накопления
Команда TPC, полученная в формате 3/3A DCI для PUSCH, UE должно предположить, что UE
мощность передачи P_{PUSCH,c}(i) для передачи PUSCH в подкадре i для
обслуживающая ячейка c вычисляется по

где:

· P_{CMAX,c}(i) – сконфигурированная мощность передачи UE, определенная в 3GPP 36.101. Стол
6.2.2-1 в подкадре i для обслуживающей соты c и {P}_{CMAX,c}(i) является линейным значением
P_{CMAX,c}(i). Значение по умолчанию для P_{CMAX,c}(i) составляет 23 дБм.

· M_{PUSCH,c}(i) – пропускная способность назначения ресурса PUSCH, выраженная в
количество блоков ресурсов, действительных для подкадра i и обслуживающей ячейки c.

· P_{O_PUSCH,c}(j) – параметр, состоящий из суммы компонентов
P_{O_NOMINAL_PUSCH,c}(j) предоставлено более высокими уровнями для j={0,1} и компонента
P_{O_UE_PUSCH,c}(j), предоставленный более высокими уровнями для j={0,1} для обслуживающей соты c.
Сообщение SIB2 необходимо расширить, чтобы оно содержало эти два компонента, но в настоящее время
их можно установить через систему атрибутов:

Config::SetDefault("ns3::LteUePowerControl::PoNominalPusch", IntegerValue (-90));
Config::SetDefault("ns3::LteUePowerControl::PoUePusch", IntegerValue (7));

· lpha_{c} (j) — 3-битный параметр, предоставляемый более высокими уровнями для ightinForelj=2,
Для j=0,1, lpha_c в t 0, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1
lpha_{c} (j) = 1. Этот параметр настраивается системой атрибутов:

Config::SetDefault("ns3::LteUePowerControl::Alpha", DoubleValue (0.8));

· PL_{c} – это оценка потерь на пути нисходящей линии связи, рассчитанная в UE для обслуживающей соты c.
в дБ и PL_{c} = referenceSignalPower – отфильтрованный RSRP более высокого уровня, где
referenceSignalPower обеспечивается более высокими уровнями и RSRP. ссылкаSignalPower
предоставляется в сообщении SIB2

· и условный случай реализован.

· f_{c}(i) является компонентом управления мощностью с обратной связью. Это текущая мощность PUSCH
контроль состояния регулировки для обслуживающей соты c.

Если включен режим накопления, f_{c}(i) определяется как:

где: elta_{PUSCH,c} — значение коррекции, также называемое командой TPC.
и включен в PDCCH с DCI; elta_{PUSCH,c}(i - K_{PUSCH}) было сообщено
PDCCH/EPDCCH с DCI для обслуживания соты c в подкадре (i-K_{PUSCH}); К_{ПУЩ} =
4 для ФДД.

Если UE достигло P_{CMAX,c}(i) для обслуживающей соты c, положительные команды TPC для
обслуживающая ячейка c не накапливается. Если UE достигло минимальной мощности, отрицательный
Команды TPC не накапливаются. Минимальная мощность UE определена в TS36.101.
раздел 6.2.3. Значение по умолчанию: -40 дБм.

Если режим накопления не включен, f_{c}(i) определяется как:

где: elta_{PUSCH,c} — значение коррекции, также называемое командой TPC.
и включен в PDCCH с DCI; elta_{PUSCH,c}(i - K_{PUSCH}) было сообщено
PDCCH/EPDCCH с DCI для обслуживания соты c в подкадре (i-K_{PUSCH}); К_{ПУЩ} =
4 для ФДД.

Преобразование поля команды TPC в формате DCI 0/3/4 в абсолютное и накопленное
Значения elta_{PUSCH,c} определены в TS36.231, раздел 5.1.1.1, таблица 5.1.1.1-2.

Хакеры: Запитан Контролировать для ПУКЧ
Поскольку все сообщения управления восходящим каналом являются идеальными сообщениями и не потребляют никаких радиосигналов.
ресурсы, управление мощностью восходящей линии связи для PUCCH не требуется и не реализовано.

Хакеры: Запитан Контролировать для SRS
Настройка мощности передачи UE P_{SRS} для SRS, передаваемого в подкадре i для
обслуживающая ячейка c определяется

где:

· P_{CMAX,c}(i) – сконфигурированная мощность передачи UE, определенная в 3GPP 36.101. Стол
6.2.2-1. Значение по умолчанию для P_{CMAX,c}(i) составляет 23 дБм.

· P_{SRS_OFFSET,c}(m) полустатически конфигурируется более высокими уровнями для m=0,1 для
обслуживающая камера c . Для передачи SRS задан тип триггера 0, тогда m=0,1, а для SRS
передача с заданным типом триггера 1, тогда m=1. Для K_{s} = 0 P_Srs_Offset_Value равно
вычисляется по уравнению:

Этот параметр настраивается системой атрибутов:

Config::SetDefault("ns3::LteUePowerControl::PsrsOffset", IntegerValue (7));

· M_{SRS,c} – пропускная способность передачи SRS в субкадре i для обслуживающей соты.
c выражается в количестве блоков ресурсов. В текущей реализации SRS отправляется
по всей полосе пропускания UL.

· f_{c}(i) - текущее состояние настройки управления мощностью PUSCH для обслуживающей соты c,
как определено в Хакеры: Запитан Контролировать для ПУШ

· P_{O_PUSCH,c}(j) и lpha_{c}(j) являются параметрами, определенными в Хакеры: Запитан
Контролировать для ПУШ, где j = 1 .

дробный частота Снова использовать
Обзор
В этом разделе описывается поддержка ns-3 алгоритмов повторного использования дробной частоты. Все
реализованные алгоритмы описаны в [ASHamza2013]. В настоящее время 7 алгоритмов FR
реализовано:

· ns3::LteFrNoOpAlgorithm

· ns3::LteFrHardAlgorithm

· ns3::LteFrStrictAlgorithm

· ns3::LteFrSoftAlgorithm

· ns3::LteFfrSoftAlgorithm

· ns3::LteFfrEnhancedAlgorithm

· ns3::LteFfrDistributedAlgorithm

Создан новый класс LteFfrAlgorithm, абстрактный класс для повторного использования частоты.
реализация алгоритмов. Кроме того, были добавлены два новых SAP между FR-Scheduler и FR-RRC.
[изображение] Диаграмма последовательности операций планирования с помощью алгоритма FR. UNINDENT

Figure Последовательность диаграмма of Календарное Планирование FR алгоритм показывает диаграмму последовательности
процесс планирования с помощью алгоритма FR. В начале процесса планирования планировщик
запрашивает объект FR о доступных RBG. Согласно реализации FR возвращает все RBG
доступны в ячейке или отфильтровать их на основе своей политики. Затем при попытке назначить некоторые
RBG для UE, планировщик запрашивает объект FR, разрешен ли этот RBG для этого UE. Когда ФР вернется
true, планировщик может назначить этот RBG этому UE, если планировщик не проверяет другой RBG
для этого УЭ. Опять же, ответ FR зависит от реализации и политики, применяемой к UE.

Поддержанный FR алгоритмы
Нет частота Снова использовать
Алгоритм NoOp FR (класс LteFrNoOpAlgorithm) является реализацией повторного использования полной частоты.
схема, что означает, что разделение частот между eNB одной и той же сети не выполняется.
(коэффициент повторного использования частоты, FRF равен 1). eNB использует всю полосу пропускания системы и передает
с одинаковой мощностью по всем RBG. Это простейшая схема и основной способ
работает в сети LTE. Эта схема позволяет достичь высокой пиковой скорости передачи данных. Но
с другой стороны, из-за высоких уровней помех от соседних сот, граница соты
производительность пользователей сильно ограничена.

Figure Длинный частота Снова использовать схема ниже представлена ​​частота и план питания для Full
Схема повторного использования частот.
[изображение] Схема полного повторного использования частот. UNINDENT

В ns-3 алгоритм NoOp FR всегда позволяет планировщику использовать полную полосу пропускания и позволяет
все UE использовать любой RBG. Он просто не делает ничего нового (т. е. не ограничивает eNB).
пропускная способность, алгоритм FR отключен), это простейшая реализация FrAlgorithm
class и устанавливается в eNb по умолчанию.

Жесткий частота Снова использовать
Алгоритм Hard Frequency Reuse обеспечивает простейшую схему, позволяющую уменьшить
уровень межсотовых помех. В этой схеме вся полоса частот делится на
несколько (обычно 3, 4 или 7) непересекающихся поддиапазонов. Смежные eNB распределяются с разными
поддиапазон. Коэффициент повторного использования частоты равен количеству поддиапазонов. Эта схема позволяет
значительно уменьшают ICI на границе соты, поэтому производительность пользователей соты повышается.
Но из-за того, что каждый eNB использует только одну часть всей полосы пропускания, пиковая скорость передачи данных
уровень также уменьшается на коэффициент, равный коэффициенту повторного использования.

Figure Жесткий частота Снова использовать схема ниже представлена ​​частота и план питания для Hard
Схема повторного использования частот.
[изображение] Схема повторного использования жесткой частоты. UNINDENT

В нашей реализации алгоритм Hard FR имеет только вектор RBG, доступный для eNB.
и передать его планировщику MAC во время функций планирования. Когда планировщик спрашивает, включен ли RBG
разрешено для конкретного UE, он всегда возвращает true.

Строгий частота Снова использовать
Схема Strict Frequency Reuse представляет собой комбинацию схем Full и Hard Frequency Reuse. Это
состоит из разделения пропускной способности системы на две части, которые будут иметь разные
повторное использование частот. Внутри каждой соты используется один общий поддиапазон полосы пропускания системы.
(повторное использование частоты-1), а другая часть полосы пропускания делится между
соседних eNB, как при жестком повторном использовании частоты (повторное использование частоты-N, N>1), чтобы создать
один поддиапазон с низким уровнем межсотовых помех в каждом секторе. Центральные UE будут
предоставляется с полностью повторно используемыми частотными фрагментами, в то время как UE на границе соты с ортогональными фрагментами.
Это означает, что внутренние UE из одной соты не имеют общего спектра с краевыми UE из другой соты.
вторая ячейка, что уменьшает помехи для обоих. Как можно заметить, Strict FR требует
всего N + 1 поддиапазон, и позволяет достичь RFR в середине между 1 и 3.

Figure Строгий частота Снова использовать схема ниже представлена ​​частота и план питания для Strict
Схема повторного использования частоты с коэффициентом повторного использования края ячейки N = 3.
[изображение] Схема строгого повторного использования частоты. UNINDENT

В нашей реализации алгоритм Strict FR имеет две карты, по одной для каждого поддиапазона. Если УЭ
может обслуживаться в частном поддиапазоне, его RNTI добавляется в карту m_privateSubBandUe. Если
UE может обслуживаться в пределах общего поддиапазона, его RNTI добавляется в карту m_commonSubBandUe.
Строгий алгоритм FR должен решить, в каком поддиапазоне UE должно обслуживаться. Оно использует
Измерения UE, предоставленные RRB, и сравнить их с порогом качества сигнала (это
параметр может быть легко настроен с помощью механизма атрибутов). Порог влияет на
Отношение внутреннего радиуса к радиусу ячейки.

мягкая частота Снова использовать
В схеме мягкого повторного использования частоты (SFR) каждый eNb передает по всей полосе пропускания системы,
но есть два поддиапазона, внутри UE обслуживаются с разным уровнем мощности. С
UE в центре соты делят полосу пропускания с соседними сотами, они обычно передают на более низкой скорости.
уровень мощности, чем у UE на краю соты. SFR более эффективен с точки зрения пропускной способности, чем Strict FR,
потому что он использует всю полосу пропускания системы, но также приводит к большим помехам для обоих
внутренние и пограничные пользователи соты.

Возможны два варианта схемы SFR:

· В первой версии поддиапазон, выделенный для UE на границе соты, также может использоваться
UE в центре соты, но с пониженным уровнем мощности и только в том случае, если оно не занято
UE на границе соты. Поддиапазон сотового центра доступен только центральным UE. Фигура
мягкая частота Снова использовать схема версия 1 ниже представлена ​​частота и план мощности для
эта версия схемы мягкого повторного использования частоты.
[изображение] Схема мягкого повторного использования частоты, версия 1. UNINDENT

· Во второй версии UE в центре соты не имеют доступа к поддиапазону на краю соты. В
Таким образом, каждая ячейка может использовать всю полосу пропускания системы, уменьшая при этом
помехи соседним ячейкам. С другой стороны, более низкий уровень ICI на
граница соты достигается за счет меньшего использования спектра. Фигура мягкая
частота Снова использовать схема версия 2 ниже представлена ​​частота и схема мощности для этого
вариант схемы мягкого повторного использования частот.
[изображение] Схема мягкого повторного использования частоты, версия 2. UNINDENT

Алгоритм SFR поддерживает две карты. Если UE должно обслуживаться с более низким уровнем мощности, его
RNTI добавлен в карту m_lowPowerSubBandUe. Если UE должно обслуживаться с более высокой мощностью
уровень, его RNTI добавляется в карту m_highPowerSubBandUe. Чтобы решить, с каким уровнем мощности
UE должно быть обслужено. Алгоритм SFR использует измерения UE и сравнивает их с
порог. Порог качества сигнала и PdschConfigDedicated (т. е. значение P_A) для внутреннего
и внешняя область может быть настроена системой атрибутов. SFR использует мощность нисходящей линии связи
Управление описано здесь.

мягкая дробный частота Снова использовать
Мягкое повторное использование дробной частоты (SFFR) представляет собой комбинацию строгого и мягкого повторного использования частоты.
Схемы повторного использования. В то время как Strict FR не использует поддиапазоны, выделенные для внешней области в
соседних сот, мягкий FFR использует эти поддиапазоны для внутренних UE с низкой мощностью передачи. В виде
В результате SFFR, как и SFR, использует поддиапазон с высоким уровнем мощности передачи и с низким
уровень мощности передачи. В отличие от Soft FR и Strict FR, Soft FFR использует общий
поддиапазон, который может повысить пропускную способность внутренних пользователей.

Figure мягкая дробный дробный частота Снова использовать схема ниже представлена ​​частота и
план питания для мягкого повторного использования дробной частоты.
[изображение] Мягкая дробная схема повторного использования дробной частоты. UNINDENT

Повышенная дробный частота Снова использовать
Enhanced Fractional Frequency Reuse (EFFR), описанный в [ZXie2009], определяет 3 типа ячеек.
для непосредственно соседних ячеек в сотовой системе, и резервы для каждого типа ячейки a
часть всей полосы частот, названная первичная Segment, который среди разнотипных клеток
должно быть ортогональным. Остальные подканалы составляют Старшая школа Segment,
первичная Segment клеточного типа является в то же время частью Старшая школа Сегменты
принадлежащие к двум другим типам клеток. Каждая ячейка может занимать все подканалы своего первичная
Segment по желанию, тогда как только часть подканалов в Старшая школа Segment может быть использован
этой ячейкой с учетом помех. первичная Segment каждая клетка делится
в часть повторного использования-3 и часть повторного использования-1. Часть reuse-1 может повторно использоваться всеми типами ячеек.
в системе, в то время как часть reuse-3 может быть повторно использована только другими теми же типами
ячеек (т. е. подканалы повторного использования-3 не могут повторно использоваться непосредственно соседними ячейками). На
Старшая школа Segment ячейка действует как гость, и занятие вторичных подканалов
фактически повторно использовать первичные подканалы, принадлежащие непосредственно соседним ячейкам, таким образом
повторное использование на Старшая школа Segment каждой ячейкой должны соответствовать двум правилам:

· контролировать перед использованием

· повторное использование ресурсов на основе оценки SINR

Каждая ячейка все время прослушивает каждый вторичный подканал. А до оккупации это
выполняет оценку SINR в соответствии с собранной информацией о качестве канала (CQI) и
выбирает ресурсы с лучшими значениями оценки для повторного использования. Если значение CQI для RBG выше
настроенный порог для некоторого пользователя, передача для этого пользователя может быть выполнена с использованием этого
РБГ.

В [ZXie2009] описан процесс планирования, он состоит из трех шагов и двух
политики планирования. Поскольку ни один из реализованных в настоящее время планировщиков не допускает этого
поведение, были применены некоторые упрощения. В нашей реализации reuse-1 подканалы могут
использоваться только пользователями сотового центра. Подканалы Reuse-3 могут использоваться пограничными пользователями, и только
если нет пограничного пользователя, передача для пользователей сотового центра может обслуживаться в повторном использовании-3.
подканалы.

Figure Повышенная дробный дробный частота Снова использовать схема ниже представлена ​​частота и
план электропитания для расширенного повторного использования дробной частоты.
[изображение] Усовершенствованная схема повторного использования дробной частоты. UNINDENT

Распределенный дробный частота Снова использовать
Этот алгоритм повторного использования распределенной дробной частоты был представлен в [DKimura2012]. Это
автоматически оптимизирует поддиапазоны на границе соты, фокусируясь на пользовательском распределении (в
в частности, распределение мощности приема). Этот алгоритм адаптивно выбирает RB для
поддиапазон границы соты на основе информации о координации от соседних сот и уведомляет
базовые станции соседних сот, которые он выбрал для использования в краевом поддиапазоне.
Базовая станция каждой соты использует полученную информацию и следующее уравнение для
вычислить метрику границы полосы соты A_{k} для каждого RB.

где J — множество соседних ячеек, X_{j,k}=0,1 — RNTP от j-й соседней ячейки.
Он принимает значение 1, когда k-й RB в j-й соседней ячейке используется в качестве ребра ячейки
поддиапазон и 0 в противном случае. Символ w_{j} обозначает вес относительно соседней ячейки j,
то есть количество пользователей, для которых разница между мощностью сигнала
принимаемого от обслуживающей соты i и мощность сигнала, принимаемого от соседнего
ячейке j меньше порогового значения (т. е. количество пользователей вблизи края ячейки в
служебная ячейка). Большая разница принимаемой мощности означает, что пользователи на краю соты в i-м
соты испытывают сильные помехи от j-й соты.

РБ, для которого метрика A_{k} наименьшая, считается наименее затронутым
помехи от другой соты. Обслуживающая ячейка выбирает сконфигурированное количество RB как
поддиапазон края ячейки в порядке возрастания A_{k}. В результате РБ, в которых
количество пользователей на краю соты, получающих сильные помехи от соседних базовых станций,
выбран.

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

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

Figure Последовательность диаграмма of Распределенный частота Снова использовать Схема ниже представлена ​​последовательность
диаграмма распределенной схемы повторного использования дробных частот.
[изображение] Схема последовательности распределенной схемы повторного использования частот. UNINDENT

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

· LteHelper, который занимается настройкой сети радиодоступа LTE, т.к.
а также координировать установку и выпуск носителей EPS. LteHelper класс
предоставляет как определение API, так и его реализацию.

· ЭпХелпер, который отвечает за настройку Evolved Packet Core.
ЭпХелпер class — это абстрактный базовый класс, который предоставляет только определение API; в
реализация делегирована дочерним классам, чтобы обеспечить возможность использования различных EPC
сетевые модели.

Можно создать простую симуляцию только для LTE, используя LteHelper в одиночку или к
создавать полные симуляции LTE-EPC, используя оба LteHelper и ЭпХелпер, Когда оба
используются помощники, они взаимодействуют по принципу «хозяин-раб», с LteHelper быть мастером
который взаимодействует непосредственно с пользовательской программой, и ЭпХелпер работать «под колпаком»
настроить EPC при явных методах, вызываемых LteHelper. Точные взаимодействия
показано на рисунке Последовательность диаграмма of взаимодействие между LteHelper и
ЭпХелпер.
[изображение] Диаграмма последовательности взаимодействия между LteHelper и EpcHelper.UNINDENT

Информация о пользователе Документация
проверка данных
Мы предполагаем, что читатель уже знаком с тем, как использовать симулятор ns-3 для запуска универсальных
программы моделирования. Если это не так, мы настоятельно рекомендуем читателю обратиться к
[ns3учебник].

Применение Обзор
Модель ns-3 LTE представляет собой программную библиотеку, которая позволяет моделировать сети LTE,
опционально включая Evolved Packet Core (EPC). Процесс выполнения таких
Моделирование обычно включает следующие этапы:

1. определять сценарий быть симулированным

2. Написать a моделирование программа который воссоздает желаемый сценарий
топология/архитектура. Это делается путем доступа к библиотеке моделей ns-3 LTE с помощью
ns3::LteHelper API, определенный в src/lte/помощник/lte-helper.h.

3. Указывать конфигурация параметры объектов, которые используются для
моделирование. Это можно сделать с помощью входных файлов (через ns3::ConfigStore) Или
непосредственно в программе моделирования.

4. Настроить желанный выходной будет производиться симулятором

5. Run симуляция.

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

Базовый моделирование программа
Вот минимальная программа моделирования, необходимая для моделирования только LTE.
(без ЭЦП).

1. Исходный шаблон:

#включают
#включать
#включают
#включают

используя пространство имен ns3;

int main (int argc, char * argv [])
{
// далее следует остальная часть программы моделирования

2. Создайте LteHelper объект:

Птр lteHelper = СоздатьОбъект ();

Это создаст некоторые общие объекты (например, объект Channel) и предоставит
методы для добавления eNB и UE и их настройки.

3. Создавать Узел объекты для eNB и UE:

NodeContainer enbNodes;
enbNodes.Создать (1);
NodeContainer ueNodes;
ueNodes.Создать (2);

Обратите внимание, что указанные выше экземпляры Node на данный момент все еще не имеют протокола LTE.
стек установлен; это просто пустые узлы.

4. Настройте модель Mobility для всех узлов:

MobilityHelper мобильность;
мобильность.SetMobilityModel ("ns3 :: ConstantPositionMobilityModel");
мобильность.Установить (enbNodes);
мобильность.SetMobilityModel ("ns3 :: ConstantPositionMobilityModel");
мобильность.Установить (ueNodes);

Приведенное выше поместит все узлы в координаты (0,0,0). Пожалуйста, обратитесь к
документация по модели мобильности ns-3 о том, как установить собственную позицию или настроить
движение узла.

5. Установите стек протоколов LTE на eNB:

EnbDevs NetDeviceContainer;
enbDevs = lteHelper->InstallEnbDevice (enbNodes);

6. Установите стек протоколов LTE на UE:

NetDeviceContainer ueDevs;
ueDevs = lteHelper->InstallUeDevice (ueNodes);

7. Присоедините UE к eNB. Это настроит каждое UE в соответствии с eNB.
конфигурации и создайте RRC-соединение между ними:

lteHelper->Прикрепить (ueDevs, enbDevs.Get (0));

8. Активируйте однонаправленный радиоканал данных между каждым UE и eNB, к которому оно подключено:

перечисление EpsBearer::Qci q = EpsBearer::GBR_CONV_VOICE;
Носитель EpsBearer (q);
lteHelper->ActivateDataRadioBearer (ueDevs, носитель);

этот метод также активирует два генератора трафика насыщения для этого носителя, один
в восходящем канале и один в нисходящем.

9. Установите время остановки:

Симулятор :: Стоп (Секунды (0.005));

Это необходимо, иначе симуляция будет длиться вечно, потому что (среди прочего)
событие start-of-subframe запланировано повторно, и планировщик симулятора ns-3 будет
следовательно, никогда не заканчиваются события.

10. Запустите симуляцию:

Симулятор :: Беги ();

11. Очистка и выход:

Симулятор :: Уничтожить ();
0 вернуться;
}

Чтобы узнать, как компилировать и запускать программы моделирования, обратитесь к [ns3tutorial].

Конфигурация of LTE модель параметры
Все соответствующие параметры модели LTE управляются через систему атрибутов ns-3.
Пожалуйста, обратитесь к [ns3tutorial] и [ns3manual] для получения подробной информации обо всех
возможные методы для этого (переменные среды, C++ API, GtkConfigStore...).

Далее мы просто кратко суммируем, как это сделать, используя входные файлы вместе с
хранилище конфигурации ns-3. Прежде всего, вам нужно поместить следующее в вашу симуляцию
программа, сразу после main () начинается:

Командная строка командной строки;
cmd.Parse(argc, argv);
ConfigStore inputConfig;
inputConfig.ConfigureDefaults ();
// повторный анализ, чтобы вы могли переопределить значения по умолчанию из командной строки
cmd.Parse(argc, argv);

чтобы вышеперечисленное работало, убедитесь, что вы также #включают "ns3/config-store.h". Теперь создайте
текстовый файл с именем (например) ввод-defaults.txt указав новые значения по умолчанию, которые
вы хотите использовать для некоторых атрибутов:

по умолчанию ns3::LteHelper::Scheduler "ns3::PfFfMacScheduler"
по умолчанию ns3::LteHelper::PathlossModel "ns3::FriisSpectrumPropagationLossModel"
по умолчанию ns3::LteEnbNetDevice::UlBandwidth "25"
по умолчанию ns3::LteEnbNetDevice::DlBandwidth "25"
по умолчанию ns3::LteEnbNetDevice::DlEarfcn "100"
по умолчанию ns3::LteEnbNetDevice::UlEarfcn "18100"
по умолчанию ns3::LteUePhy::TxPower "10"
по умолчанию ns3::LteUePhy::NoiseFigure "9"
по умолчанию ns3::LteEnbPhy::TxPower "30"
по умолчанию ns3::LteEnbPhy::NoiseFigure "5"

Предположим, ваша программа моделирования называется src/lte/примеры/lte-sim-с-вводом, Вы можете
теперь передайте эти настройки программе моделирования следующим образом:

./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Load --ns3::ConfigStore::FileFormat=RawText" --run src/lte/examples/lte-sim-with-input

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

./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Сохранить --ns3::ConfigStore::FileFormat=RawText" --run src/lte/examples/lte-sim-with-input

обратите внимание, что приведенное выше будет помещено в файл ввод-defaults.txt ВСЕ значения по умолчанию, которые
зарегистрированы в вашей конкретной сборке симулятора, включая множество не-LTE
атрибутов.

Настроить LTE MAC Планировщик
Здесь пользователь может выбрать несколько типов планировщика LTE MAC. Пользователь может использовать следующие
коды для определения типа планировщика:

Птр lteHelper = СоздатьОбъект ();
lteHelper->SetSchedulerType("ns3::FdMtFfMacScheduler"); // Планировщик FD-MT
lteHelper->SetSchedulerType("ns3::TdMtFfMacScheduler"); // Планировщик TD-MT
lteHelper->SetSchedulerType("ns3::TtaFfMacScheduler"); // Планировщик ТТА
lteHelper->SetSchedulerType("ns3::FdBetFfMacScheduler"); // Планировщик FD-BET
lteHelper->SetSchedulerType("ns3::TdBetFfMacScheduler"); // Планировщик TD-BET
lteHelper->SetSchedulerType("ns3::FdTbfqFfMacScheduler"); // Планировщик FD-TBFQ
lteHelper->SetSchedulerType("ns3::TdTbfqFfMacScheduler"); // Планировщик TD-TBFQ
lteHelper->SetSchedulerType("ns3::PssFfMacScheduler"); //Планировщик PSS

TBFQ и PSS имеют больше параметров, чем другие планировщики. Пользователи могут определять эти параметры
следующим образом:

* Планировщик TBFQ::

Птр lteHelper = СоздатьОбъект ();
lteHelper->SetSchedulerAttribute("DebtLimit", IntegerValue(yourvalue)); // значение по умолчанию -625000 байт (-5Мб)
lteHelper->SetSchedulerAttribute("CreditLimit", UintegerValue(yourvalue)); // значение по умолчанию 625000 байт (5Мб)
lteHelper->SetSchedulerAttribute("TokenPoolSize", UintegerValue(ваше значение)); // значение по умолчанию 1 байт
lteHelper->SetSchedulerAttribute("CreditableThreshold", UintegerValue(yourvalue)); // значение по умолчанию 0

* Планировщик PSS::

Птр lteHelper = СоздатьОбъект ();
lteHelper->SetSchedulerAttribute("nMux", UIntegerValue(yourvalue)); // максимальное количество UE, выбранное планировщиком TD
lteHelper->SetSchedulerAttribute("PssFdSchedulerType", StringValue("CoItA")); // Тип планировщика PF в PSS

В TBFQ значения по умолчанию лимита долга и кредитного лимита установлены на -5 МБ и 5 МБ.
соответственно на основе статьи [FABokhari2009]. Текущая реализация не учитывает
кредитный порог (C = 0). В PSS, если пользователь не определяет nMux, PSS установит это значение равным
половина всего УЭ. Планировщик FD по умолчанию — PFsch.

Кроме того, скорость генерации токенов в TBFQ и целевая скорость передачи данных в PSS должны быть
настраивается с помощью гарантированной скорости передачи данных (GBR) или максимальной скорости передачи данных (MBR) в канале EPC QoS.
параметры. Пользователи могут использовать следующие коды для определения GBR и MBR как в нисходящей, так и в
восходящая линия:

Птр lteHelper = СоздатьОбъект ();
enum EpsBearer::Qci q = EpsBearer::yourvalue; // определяем тип Qci
GbrQosИнформация qos;
qos.gbrDl = ваше значение; // Нисходящий GBR
qos.gbrUl = ваше значение; // восходящий канал GBR
qos.mbrDl = ваше значение; // MBR нисходящего канала
qos.mbrUl = ваше значение; // MBR восходящего канала
Носитель EpsBearer (q, qos);
lteHelper->ActivateDedicatedEpsBearer(ueDevs, Bearer, EpcTft::Default());

В PSS TBR получается из GBR в параметрах QoS уровня несущей. В TBFQ генерация токенов
скорость получается из настройки MBR в параметрах QoS уровня несущей, поэтому
необходимо настроить последовательно. Для трафика с постоянной скоростью передачи данных (CBR) рекомендуется
установить MBR на GBR. Для трафика с разбросом битрейта (VBR) предлагается устанавливать MBR k раз.
больше, чем GBR, чтобы покрыть пиковую скорость трафика. В текущей реализации k равно
установлен в три на основании статьи [FABokhari2009]. Кроме того, текущая версия TBFQ не
учитывайте длину заголовка RLC и заголовка PDCP в MBR и GBR. Другим параметром в TBFQ является
скорость поступления пакетов. Этот параметр рассчитывается в планировщике и равен прошлому
средняя пропускная способность, которая используется в планировщике PF.

Многие полезные атрибуты модели LTE-EPC будут описаны далее.
подразделы. Тем не менее, есть много атрибутов, которые явно не упоминаются в
проектная или пользовательская документация, но которые четко задокументированы с использованием атрибута ns-3
система. Вы можете легко распечатать список атрибутов данного объекта вместе с
их описание и передача значений по умолчанию --PrintAttributes= к программе моделирования,
как это:

./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteHelper"

Вы также можете попробовать другие объекты LTE и EPC, например:

./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbNetDevice"
./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbMac"
./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbPhy"
./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteUePhy"
./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::PointToPointEpcHelper"

Симуляторы Результат
Модель ns-3 LTE в настоящее время поддерживает вывод в файл уровней PHY, MAC, RLC и PDCP.
Ключевые показатели эффективности (KPI). Вы можете включить его следующим образом:

Птр lteHelper = СоздатьОбъект ();

// настроить все сценарии моделирования здесь...

lteHelper->EnablePhyTraces ();
lteHelper->EnableMacTraces ();
lteHelper->ВключитьRlcTraces ();
lteHelper->ВключитьPdcpTraces ();

Симулятор :: Беги ();

KPI RLC и PDCP рассчитываются в течение определенного интервала времени и сохраняются в файлах ASCII, два из которых
KPI RLC и два для KPI PDCP, в каждом случае один для восходящей линии связи и один для нисходящей линии связи. Время
продолжительность интервала можно контролировать с помощью атрибута
ns3::RadioBearerStatsCalculator::EpochDuration.

Столбцы файлов KPI RLC следующие (одинаковые для восходящего и нисходящего каналов):

1. время начала интервала измерения в секундах с начала симуляции

2. время окончания интервала измерения в секундах с начала симуляции

3. Идентификатор ячейки

4. уникальный идентификатор UE (IMSI)

5. специфический для соты идентификатор UE (RNTI)

6. Идентификатор логического канала

7. Количество переданных RLC PDU

8. Всего передано байтов.

9. Количество полученных RLC PDU

10. Всего полученных байтов

11. Средняя задержка RLC PDU в секундах

12. Стандартное отклонение задержки RLC PDU

13. Минимальное значение задержки RLC PDU

14. Максимальное значение задержки RLC PDU

15. Средний размер PDU RLC, в байтах

16. Стандартное отклонение размера PDU RLC

17. Минимальный размер PDU RLC

18. Максимальный размер PDU RLC

Точно так же столбцы файлов KPI PDCP следующие (опять же, то же самое для восходящей линии связи).
и нисходящий канал):

1. время начала интервала измерения в секундах с начала симуляции

2. время окончания интервала измерения в секундах с начала симуляции

3. Идентификатор ячейки

4. уникальный идентификатор UE (IMSI)

5. специфический для соты идентификатор UE (RNTI)

6. Идентификатор логического канала

7. Количество переданных PDU PDCP

8. Всего передано байтов.

9. Количество полученных PDU PDCP

10. Всего полученных байтов

11. Средняя задержка PDU PDCP в секундах

12. Стандартное отклонение задержки PDU PDCP

13. Минимальное значение задержки PDU PDCP

14. Максимальное значение задержки PDU PDCP

15. Средний размер PDU PDCP, в байтах

16. Стандартное отклонение размера PDU PDCP

17. Минимальный размер PDU PDCP

18. Максимальный размер PDU PDCP

KPI MAC в основном являются отслеживанием распределения ресурсов, сообщаемого планировщиком при
начало каждого подкадра. Они хранятся в файлах ASCII. Для KPI MAC нисходящего канала
формат следующий:

1. Время симуляции в секундах, при котором распределение указывается планировщиком

2. Идентификатор ячейки

3. уникальный идентификатор UE (IMSI)

4. Номер кадра

5. Номер подрамника

6. специфический для соты идентификатор UE (RNTI)

7. МКС ТБ 1

8. размер ТБ 1

9. MCS ТБ 2 (0, если нет)

10. размер ТБ 2 (0, если нет)

в то время как для восходящих MAC KPI используется следующий формат:

1. Время симуляции в секундах, при котором распределение указывается планировщиком

2. Идентификатор ячейки

3. уникальный идентификатор UE (IMSI)

4. Номер кадра

5. Номер подрамника

6. специфический для соты идентификатор UE (RNTI)

7. MCS туберкулеза

8. размер ТБ

Имена файлов, используемых для вывода MAC KPI, можно настроить с помощью атрибутов ns-3.
ns3::MacStatsCalculator::DlOutputFilename и ns3::MacStatsCalculator::UlOutputFilename.

PHY KPI распределены в семи разных файлах, настраиваемых с помощью атрибутов.

1. ns3::PhyStatsCalculator::DlRsrpSinrFilename

2. ns3::PhyStatsCalculator::UeSinrFilename

3. ns3::PhyStatsCalculator::InterferenceFilename

4. ns3::PhyStatsCalculator::DlTxOutputFilename

5. ns3::PhyStatsCalculator::UlTxOutputFilename

6. ns3::PhyStatsCalculator::DlRxOutputFilename

7. ns3::PhyStatsCalculator::UlRxOutputFilename

В файле RSRP/SINR доступно следующее содержимое:

1. Время симуляции в секундах, при котором распределение указывается планировщиком

2. Идентификатор ячейки

3. уникальный идентификатор UE (IMSI)

4. РСРП

5. Линейное среднее по всем RB SINR нисходящего канала в линейных единицах.

Содержимое файла UE SINR:

1. Время симуляции в секундах, при котором распределение указывается планировщиком

2. Идентификатор ячейки

3. уникальный идентификатор UE (IMSI)

4. SINR восходящей линии связи в линейных единицах для UE

В названии файла интерференции содержится следующее:

1. Время симуляции в секундах, при котором распределение указывается планировщиком

2. Идентификатор ячейки

3. Список значений помех на РБ

В файлы передачи UL и DL включаются следующие параметры:

1. Время моделирования в миллисекундах

2. Идентификатор ячейки

3. уникальный идентификатор UE (IMSI)

4. РНТИ

5. Уровень передачи

6. МКС

7. размер ТБ

8. Версия с резервированием

9. Флаг индикатора новых данных

И, наконец, в файлы приема UL и DL включаются следующие параметры:

1. Время моделирования в миллисекундах

2. Идентификатор ячейки

3. уникальный идентификатор UE (IMSI)

4. РНТИ

5. Режим передачи

6. Уровень передачи

7. МКС

8. размер ТБ

9. Версия с резервированием

10. Флаг индикатора новых данных

11. Правильность приема ТБ

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

Замирание Следы Поколение
Можно генерировать следы затухания, используя специальный скрипт Matlab, поставляемый с
код (/lte/модель/fading-traces/fading-trace-generator.m). Этот скрипт уже включает
типичные конфигурации отводов для трех сценариев 3GPP (т. е. пешеходный, автомобильный и
городской, как определено в Приложении B.2 к [TS36104]); однако пользователи также могут представить свои
конкретные конфигурации. Список настраиваемых параметров приведен в
следующие:

· fc : используемая частота (влияет на вычисление доплеровской скорости).

· v_km_h : скорость пользователей

· трассировкаДлительность : продолжительность в секундах общей длины трассы.

· числоRB : номер оцениваемого блока ресурсов.

· день : тег, который будет применен к сгенерированному файлу.

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

Следует отметить, что модуль ns-3 LTE способен работать с любым файлом трассировки замираний.
который соответствует описанному выше формату ASCII. Следовательно, другие внешние инструменты могут быть
используется для создания пользовательских трасс затухания, таких как, например, другие симуляторы или
экспериментальные устройства.

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

· Имя файла трассировки : имя загружаемой трассы (абсолютный или относительный путь).
укажите путь, откуда выполняется программа моделирования);

· длина трассы : продолжительность трассировки в секундах;

· ОбразцыNum : количество образцов;

· размер окна : размер окна выборки затухания в секундах;

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

Конфигурация по умолчанию сценария Matlab обеспечивает трассировку длиной 10 секунд, состоящую из
10,000 1 выборок (т. е. 1 выборка на TTI = 0.5 мс) и используется с размером окна XNUMX секунды.
амплитуда. Это также значения по умолчанию для указанных выше параметров, используемых в
тренажер; поэтому их установки можно избежать, если след замирания их соблюдает.

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

Птр lteHelper = СоздатьОбъект ();
lteHelper->SetFadingModel("ns3::TraceFadingLossModel");

И для установки параметров:

lteHelper->SetFadingModelAttribute("TraceFilename", StringValue("src/lte/model/fading-traces/fading_trace_EPA_3kmph.fad"));
lteHelper->SetFadingModelAttribute("TraceLength", TimeValue (Seconds (10.0)));
lteHelper->SetFadingModelAttribute("SamplesNum", UintegerValue (10000));
lteHelper->SetFadingModelAttribute("WindowSize", TimeValue (Seconds (0.5)));
lteHelper->SetFadingModelAttribute("RbNum", UintegerValue (100));

Следует отметить, что, Имя файла трассировки не имеет значения по умолчанию, поэтому должен
всегда задавать явно.

Симулятор изначально предоставляет три трассы замираний, сгенерированные в соответствии с
конфигурации, определенные в Приложении B.2 к [TS36104]. Эти следы доступны в
папку. src/lte/модель/выцветание-следы/). Отрывок из этих следов представлен в
следующие цифры.
[изображение: след затухания 3 км/ч] [изображение] Фрагмент следа затухания, включенный в
симулятор для пешеходного сценария (скорость 3 км/ч)..UNINDENT
[изображение: след затухания 60 км/ч] [изображение] Фрагмент следа затухания, включенный в
симулятор для автомобильного сценария (скорость 60 км/ч)..БЕЗ ИСПОЛЬЗОВАНИЯ
[изображение: след затухания 3 км/ч] [изображение] Фрагмент следа затухания, включенный в
симулятор для городского сценария (скорость 3 км/ч)..UNINDENT

Мобильность Модель Здания
Теперь объясним на примерах, как пользоваться моделью зданий (в частности,
МобильностьСтроительствоИнфо и ЗданиеРаспространениеМодель классы) в симуляции ns-3
программа для настройки сценария моделирования LTE, который включает здания и внутренние узлы.

1. Заголовочные файлы, которые необходимо включить:

#включают
#включают
#включают

2. Выбор модели Pathloss:

Птр lteHelper = СоздатьОбъект ();

lteHelper->SetAttribute("PathlossModel", StringValue("ns3::BuildingsPropagationLossModel"));

3. Выбор диапазона EUTRA

Выбор рабочей частоты модели распространения должен быть сделан с
стандартная система атрибутов ns-3, как описано в соответствующем разделе ("Конфигурация
параметры модели LTE") с помощью параметров DlEarfcn и UlEarfcn, например:

lteHelper->SetEnbDeviceAttribute("DlEarfcn", UintegerValue (100));
lteHelper->SetEnbDeviceAttribute("UlEarfcn", UintegerValue (18100));

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

1. Выбор модели мобильности:

MobilityHelper мобильность;
мобильность.SetMobilityModel ("ns3 :: ConstantPositionMobilityModel");

Следует отметить, что может использоваться любая модель мобильности.

2. Создание здания:

двойной x_min = 0.0;
двойной x_max = 10.0;
двойной y_min = 0.0;
двойной y_max = 20.0;
двойной z_min = 0.0;
двойной z_max = 10.0;
Ptr b = CreateObject ();
b-> SetBoundaries (Box (x_min, x_max, y_min, y_max, z_min, z_max));
b-> SetBuildingType (Здание :: Жилой);
b-> SetExtWallsType (Здание :: ConcreteWithWindows);
б-> SetNFloors (3);
b-> SetNRoomsX (3);
b-> SetNRoomsY (2);

Это создаст жилое здание с основанием 10 х 20 метров и высотой
10 метров, наружные стены из бетона с окнами; в здании три
этажей и имеет внутреннюю сетку 3 x 2 комнат одинакового размера.

3. Создание и размещение узла:

ueNodes.Создать (2);
мобильность.Установить (ueNodes);
BuildingsHelper :: Установить (ueNodes);
NetDeviceContainer ueDevs;
ueDevs = lteHelper->InstallUeDevice (ueNodes);
Ptr mm0 = enbNodes.Get (0) -> GetObject ();
Ptr mm1 = enbNodes.Get (1) -> GetObject ();
mm0-> SetPosition (Vector (5.0, 5.0, 1.5));
mm1-> SetPosition (Vector (30.0, 40.0, 1.5));

4. Завершите настройку модели здания и мобильности:

BuildingsHelper :: MakeMobilityModelConsistent ();

См. Документацию зданий модуль для получения более подробной информации.

PHY Ошибка Модель
Модель физической ошибки состоит из модели ошибки данных и ошибки управления нисходящей линии связи.
модель, обе активны по умолчанию. Их можно отключить с помощью ns3.
система атрибутов, в деталях:

Config::SetDefault("ns3::LteSpectrumPhy::CtrlErrorModelEnabled", BooleanValue (false));
Config::SetDefault("ns3::LteSpectrumPhy::DataErrorModelEnabled", BooleanValue (false));

MIMO Модель
В этом подразделе мы иллюстрируем, как настроить параметры MIMO. LTE определяет 7 типов
режимов передачи:

· Режим передачи 1: SISO.

· Режим передачи 2: MIMO Tx Diversity.

· Режим передачи 3: MIMO Spatial Multiplexity Open Loop.

· Режим передачи 4: замкнутый контур пространственного мультиплексирования MIMO.

· Режим передачи 5: Многопользовательский MIMO.

· Режим передачи 6: однослойное предварительное кодирование с замкнутым контуром.

· Режим передачи 7: порт одной антенны 5.

Согласно реализованной модели, тренажер включает в себя первые три режима передачи
типы. По умолчанию используется режим передачи 1 (SISO). Чтобы изменить значение по умолчанию
Режим передачи, который будет использоваться, атрибут Режим передачи по умолчанию Лтеенбрррк
использоваться, как показано ниже:

Config::SetDefault("ns3::LteEnbRrc::DefaultTransmissionMode", UintegerValue (0)); // СИСО
Config::SetDefault("ns3::LteEnbRrc::DefaultTransmissionMode", UintegerValue (1)); // Разнесение MIMO Tx (1 ​​уровень)
Config::SetDefault("ns3::LteEnbRrc::DefaultTransmissionMode", UintegerValue (2)); // Пространственное мультиплексирование MIMO (2 уровня)

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

void TransmissionModeConfigurationUpdate (uint16_t rnti, uint8_t txMode);

Этот метод можно использовать как для разработки механизма принятия решения о режиме передачи (т. е. для
оптимизация режима передачи в соответствии с состоянием канала и/или пользовательским
требованиям) и для ручного переключения со сценария моделирования. В последнем случае
переключение может быть выполнено, как показано ниже:

Птр lteEnbDev = enbDevs.Get (0)->GetObject ();
значение указателя ptrval;
enbNetDev->GetAttribute("FfMacScheduler", ptrval);
Птр rrsched = ptrval.Get ();
Simulator::Schedule (Seconds (0.2), &RrFfMacScheduler::TransmissionModeConfigurationUpdate, rrsched, rnti, 1);

Наконец, реализованная модель может быть реконфигурирована в соответствии с различными моделями MIMO с помощью
обновление значений усиления (единственное ограничение состоит в том, что усиление должно быть постоянным во время
время выполнения симуляции и общее для слоев). Усиление каждого режима передачи может быть
изменено в соответствии со стандартной системой атрибутов ns3, где атрибуты:
TxMode1Gain, TxMode2Gain, TxMode3Gain, TxMode4Gain, TxMode5Gain, TxMode6Gain и
TxMode7Gain. Только по умолчанию TxMode1Gain, TxMode2Gain и TxMode3Gain иметь смысл
значение, полученное с помощью _[CatreuxMIMO] (т.е. соответственно 0.0, 4.2 и -2.8
дБ).

Используйте of АнтеннаМодель
Теперь мы покажем, как связать конкретную AntennaModel с устройством eNB, чтобы смоделировать
сектор макро eNB. Для этого удобно использовать КосинусАнтеннаМодель
обеспечивается антенным модулем нс-3. Конфигурация eNB должна выполняться через
LteHelper экземпляр непосредственно перед созданием Энбнетдевице, как показано в
следующие:

lteHelper->SetEnbAntennaModelType("ns3::CosineAntennaModel");
lteHelper->SetEnbAntennaModelAttribute("Ориентация", DoubleValue(0));
lteHelper->SetEnbAntennaModelAttribute("Ширина луча", DoubleValue (60);
lteHelper->SetEnbAntennaModelAttribute("MaxGain", DoubleValue (0.0));

приведенный выше код сгенерирует модель антенны с шириной луча 60 градусов, направленной вдоль
ось Х. Ориентация измеряется в градусах от оси X, например, ориентация
90 будет указывать вдоль оси Y, а ориентация -90 будет указывать на отрицательную
направление по оси Y. Ширина луча равна -3 дБ, например, для угла обзора 60 градусов.
ширина луча усиление антенны под углом м
30 градусов от направления ориентации составляет -3 дБ.

Для создания многосекторной площадки необходимо создать разные узлы ns-3, размещенные на одном и том же
положение и настроить отдельные Энбнетдевице с разной ориентацией антенны
установлен на каждом узле.

Радио Окружающая среда Карты
Используя класс РадиоОкружающая средаКартаHelper можно вывести в файл Радио
Environment Map (REM), т. е. однородная двумерная сетка значений, представляющая
Отношение сигнал/шум в нисходящем канале по отношению к eNB, имеющему наибольшую
сигнал в каждой точке. Можно указать, следует ли генерировать REM для данных или
канал управления. Также пользователь может установить RbId, для которого будет генерироваться REM. RbID по умолчанию
равно -1, что означает, что REM будет генерироваться с усреднением отношения сигнал/шум от всех
РБ.

Для этого вам просто нужно добавить следующий код в вашу программу моделирования в сторону
конец, прямо перед вызовом Simulator::Run():

Птр remHelper = СоздатьОбъект ();
remHelper->SetAttribute("ChannelPath", StringValue("/ChannelList/0"));
remHelper->SetAttribute("OutputFile", StringValue("rem.out"));
remHelper->SetAttribute("XMin", DoubleValue (-400.0));
remHelper->SetAttribute("XMax", DoubleValue (400.0));
remHelper->SetAttribute("XRes", UintegerValue (100));
remHelper->SetAttribute("YMin", DoubleValue (-300.0));
remHelper->SetAttribute("YMax", DoubleValue (300.0));
remHelper->SetAttribute("YRes", UintegerValue (75));
remHelper->SetAttribute("Z", DoubleValue (0.0));
remHelper->SetAttribute("UseDataChannel", BooleanValue (true));
remHelper->SetAttribute("RbId", IntegerValue (10));
remHelper->Установить ();

Путем настройки атрибутов РадиоОкружающая средаКартаHelper объект, как показано выше, вы
может настроить параметры генерируемого REM. Обратите внимание, что каждый
РадиоОкружающая средаКартаHelper экземпляр может генерировать только один REM; если вы хотите генерировать больше
REM, вам нужно создать отдельный экземпляр для каждого REM.

Обратите внимание, что генерация REM очень требовательна, в частности:

· потребление оперативной памяти составляет примерно 5 КБ на пиксель. Например, РЭМ
при разрешении 500x500 потребуется около 1.25 Гб памяти, а при разрешении
Для разрешения 1000x1000 потребуется около 5 ГБ (слишком много для обычного ПК на момент написания этой статьи).
пишу). Чтобы решить эту проблему, REM генерируется на последовательных шагах, с каждым
шаг, оценивающий не более количества пикселей, определяемого значением
атрибут RadioEnvironmentMapHelper::MaxPointsPerIteration.

· если вы сгенерируете БДГ в начале симуляции, это замедлит
выполнение остальной части моделирования. Если вы хотите сгенерировать REM для программы
а также использовать ту же программу для получения результатов моделирования, рекомендуется добавить
переключатель командной строки, который позволяет либо сгенерировать REM, либо запустить полный
моделирование. Для этого обратите внимание, что существует атрибут
RadioEnvironmentMapHelper:: StopWhenDone (по умолчанию: true), что заставит
симуляция останавливается сразу после создания REM.

REM хранится в файле ASCII в следующем формате:

· столбец 1 - это координата x

· столбец 2 - это координата y

· столбец 3 - координата z

· столбец 4 — SINR в линейных единицах

Минимальный скрипт gnuplot, позволяющий построить REM, приведен ниже:

установить карту просмотра;
установить xlabel "X"
установить ylabel "Y"
установить clabel "SINR (дБ)"
ключ сброса
построить "rem.out", используя ($1):($2):(10*log10($4)) с изображением

В качестве примера вот РЭМ, который можно получить с помощью программы-примера
lena-dual-stripe, на котором показана трехсекторная макроячейка LTE в совмещенном канале с
некоторые жилые фемтосоты случайным образом развернуты в двух многоквартирных домах.
[изображение] REM, полученный из примера lena-dual-stripe.UNINDENT

Обратите внимание, что пример программы lena-dual-stripe также генерирует вывод, совместимый с gnuplot.
файлы, содержащие информацию о позициях узлов UE и eNB, а также
здания соответственно в файлах ues.txt, enbs.txt и здания.txt, Эти могут
легко включаться при использовании gnuplot. Например, предположим, что ваш скрипт gnuplot
(например, описанный выше минимальный скрипт gnuplot) сохраняется в файле с именем
my_plot_script, выполнение следующей команды отобразит расположение UE, eNB и
постройки над РДМ:

gnuplot -p enbs.txt ues.txt building.txt my_plot_script

AMC Модель и ИКК Расчет
Симулятор предлагает две возможные схемы выбора МКС.
и, соответственно, генерация CQI. Первый основан на модуле GSoC.
[Piro2011] и работает на основе РБ. Эту модель можно активировать с помощью атрибута ns3.
система, представленная ниже:

Config::SetDefault("ns3::LteAmc::AmcModel", EnumValue (LteAmc::PiroEW2010));

В то время как решение, основанное на модели физической ошибки, можно контролировать с помощью:

Config::SetDefault("ns3::LteAmc::AmcModel", EnumValue (LteAmc::MiErrorModel));

Наконец, необходимая эффективность ПироEW2010 Модуль AMC можно настроить благодаря
Бер атрибут (), например:

Config::SetDefault("ns3::LteAmc::Ber", DoubleValue (0.00005));

Evolved пакет Основные (EPC),
Теперь мы объясним, как написать программу моделирования, которая позволяет моделировать EPC в
дополнение к сети радиодоступа LTE. Использование EPC позволяет использовать сеть IPv4.
с LTE-устройствами. Другими словами, вы сможете использовать обычные приложения ns-3.
и сокеты через IPv4 через LTE, а также для подключения сети LTE к любой другой сети IPv4
сеть, которую вы можете использовать в своей симуляции.

Прежде всего, помимо LteHelper которые мы уже представили в Базовый моделирование
программа, необходимо использовать дополнительный ЭпХелпер класс, который позаботится о создании
объекты EPC и топология сети. Обратите внимание, что вы не можете использовать ЭпХелпер прямо, как это
является абстрактным базовым классом; вместо этого вам нужно использовать один из его дочерних классов, который
обеспечивают различные реализации топологии EPC. В этом примере мы рассмотрим
PointToPointEpcHelper, который реализует EPC на основе двухточечных соединений. Чтобы использовать его,
вам нужно сначала вставить этот код в вашу программу моделирования:

Птр lteHelper = СоздатьОбъект ();
Птр epcHelper = СоздатьОбъект ();

Затем вам нужно сообщить помощнику LTE, что будет использоваться EPC:

lteHelper->SetEpcHelper (epcHelper);

вышеуказанный шаг необходим для того, чтобы помощник LTE активировал соответствующий EPC
конфигурации в соответствии с некоторой важной конфигурацией, например, когда новый eNB
или UE добавляется к моделированию, или создается однонаправленный канал EPS. Помощник EPC будет
автоматически позаботится о необходимой настройке, такой как создание канала S1 и канал S1
настраивать. Все это будет сделано без вмешательства пользователя.

призвание lteHelper->SetEpcHelper (эпхелпер) позволяет использовать EPC и имеет сторону
эффект, что любой новый Лтеенбрррк созданный будет иметь Сопоставление EpsBearerToRlc
атрибут установлен на RLC_UM_ALWAYS вместо RLC_SM_ALWAYS если последнее было по умолчанию;
в противном случае атрибут не будет изменен (например, если вы изменили значение по умолчанию на
RLC_AM_ALWAYS, его не трогают).

Следует отметить, что ЭпХелпер также автоматически создаст узел PGW и
настройте его так, чтобы он мог правильно обрабатывать трафик из/в сеть радиодоступа LTE.
Тем не менее, вам нужно добавить некоторый явный код для подключения PGW к другим сетям IPv4 (например,
Интернет). Вот очень простой пример того, как подключить один удаленный хост к
PGW по каналу точка-точка:

Птр pgw = epcHelper->GetPgwNode ();

// Создаем один RemoteHost
Удаленный хостконтейнер узла;
удаленныйHostContainer.Create (1);
Птр удаленный хост = удаленный хостконтейнер.Получить (0);
InternetStackHelper Интернет;
internet.Install(remoteHostContainer);

// Создаем интернет
Пойнттопоинтхелпер p2ph;
p2ph.SetDeviceAttribute("DataRate", DataRateValue(DataRate("100Gb/s")));
p2ph.SetDeviceAttribute("Mtu", UintegerValue (1500));
p2ph.SetChannelAttribute("Delay", TimeValue(Seconds (0.010)));
NetDeviceContainer InternetDevices = p2ph.Install (pgw, RemoteHost);
Ipv4AddressHelper ipv4h;
ipv4h.SetBase("1.0.0.0", "255.0.0.0");
Ipv4InterfaceContainer InternetIpIfaces = ipv4h.Assign (internetDevices);
// интерфейс 0 — это локальный хост, 1 — это p2p-устройство
Ipv4Address RemoteHostAddr = InternetIpIfaces.GetAddress (1);

Важно указать маршруты, чтобы удаленный хост мог получить доступ к LTE UE. Один из способов
сделать это, используя тот факт, что PointToPointEpcHelper по умолчанию назначит
для LTE UE IP-адрес в сети 7.0.0.0. Имея это в виду, достаточно сделать:

Ipv4StaticRoutingHelper ipv4RoutingHelper;
Птр remoteHostStaticRouting = ipv4RoutingHelper.GetStaticRouting (remoteHost->GetObject ());
remoteHostStaticRouting->AddNetworkRouteTo (IPv4Address ("7.0.0.0"), Ipv4Mask ("255.0.0.0"), 1);

Теперь вы должны продолжить и создать LTE eNB и UE, как описано в предыдущих разделах.
Конечно, вы можете настроить другие аспекты LTE, такие как модели потери пути и затухания. Верно
после того, как вы создали UE, вы также должны настроить их для IP-сети. Готово
следующим образом. Мы предполагаем, что у вас есть такой контейнер для узлов UE и eNodeB:

NodeContainer ueNodes;
NodeContainer enbNodes;

чтобы настроить симуляцию только LTE, вы обычно делаете что-то вроде этого:

NetDeviceContainer ueLteDevs = lteHelper->InstallUeDevice (ueNodes);
lteHelper->Прикрепить (ueLteDevs, enbLteDevs.Get (0));

чтобы настроить UE для IP-сети, вам просто нужно дополнительно сделать, например
это:

// устанавливаем стек IP на UE
InternetStackHelper Интернет;
интернет.Установить (ueNodes);

// назначаем IP-адрес UE
for (uint32_t u = 0; u < ueNodes.GetN (); ++u)
{
Птр ue = ueNodes.Get (u);
Птр ueLteDevice = ueLteDevs.Get (u);
Ipv4InterfaceContainer ueIpIface = epcHelper->AssignUeIpv4Address (NetDeviceContainer (ueLteDevice));
// устанавливаем шлюз по умолчанию для UE
Птр ueStaticRouting = ipv4RoutingHelper.GetStaticRouting (ue->GetObject ());
ueStaticRouting->SetDefaultRoute(epcHelper->GetUeDefaultGatewayAddress(), 1);
}

Активация носителей производится несколько иначе, чем то, что делается
только для моделирования LTE. Во-первых, не следует использовать метод ActivateDataRadioBearer.
при использовании ЭПК. Во-вторых, при использовании EPC активируется носитель EPS по умолчанию.
автоматически при вызове LteHelper::Attach(). В-третьих, если вы хотите настроить выделенный
Носитель EPS, вы можете сделать это с помощью метода LteHelper::ActivateDedicatedEpsBearer(). Этот
Метод принимает в качестве параметра Шаблон потока трафика (TFT), который является структурой,
идентифицирует тип трафика, который будет отображаться на выделенный однонаправленный канал EPS. Вот
пример того, как настроить выделенный однонаправленный канал для приложения в UE, обменивающемся данными на
порт 1234:

Птр tft = Создать ();
EpcTft::PacketFilter пф;
pf.localPortStart = 1234;
pf.localPortEnd = 1234;
tft->Добавить (пф);
lteHelper->ActivateDedicatedEpsBearer (ueLteDevs, EpsBearer (EpsBearer::NGBR_VIDEO_TCP_DEFAULT), tft);

вы, конечно, можете использовать пользовательские конфигурации EpsBearer и EpcTft, см.
документация doxygen о том, как это сделать.

Наконец, вы можете установить приложения на узлы LTE UE, которые взаимодействуют с удаленными
приложений через Интернет. Это делается в соответствии с обычными процедурами ns-3.
Следуя нашему простому примеру с одним удаленным хостом, вот как настроить нисходящий канал
связи с приложением UdpClient на удаленном хосте и PacketSink на
LTE UE (с использованием тех же имен переменных, что и в предыдущих фрагментах кода)

uint16_t dlPort = 1234;
PacketSinkHelper packetSinkHelper ("ns3::UdpSocketFactory",
InetSocketAddress(Ipv4Address::GetAny(), dlPort));
ApplicationContainer serverApps = packageSinkHelper.Install(ue);
serverApps.Start (секунды (0.01));
клиент UdpClientHelper (ueIpIface.GetAddress(0), dlPort);
ApplicationContainer clientApps = client.Install(remoteHost);
clientApps.Start (секунды (0.01));

Это все! Теперь вы можете начать симуляцию как обычно:

Симулятор :: Стоп (Секунды (10.0));
Симулятор :: Беги ();

. EPC эмуляция Режим
В предыдущем разделе мы использовали ссылки PointToPoint для соединения между eNB и
SGW (интерфейс S1-U) и среди eNB (интерфейсы X2-U и X2-C). LTE-модуль
поддерживает использование эмулированных ссылок вместо ссылок PointToPoint. Это достигается всего лишь
заменив собой создание LteHelper и ЭпХелпер со следующим кодом:

Птр lteHelper = СоздатьОбъект ();
Птр epcHelper = СоздатьОбъект ();
lteHelper->SetEpcHelper (epcHelper);
epcHelper->Инициализировать ();

Атрибуты ns3::EmuEpcHelper::sgwDeviceName и ns3::EmuEpcHelper::enbDeviceName
используется для установки имени устройств, используемых для транспортировки S1-U, X2-U и X2-C
интерфейсы в SGW и eNB соответственно. Сейчас мы покажем, как это делается на
пример, где мы выполняем пример программы лена-простой-epc-emu с помощью двух виртуальных
Ethernet-интерфейсы.

Первым делом строим ns-3 соответствующим образом:

# настроить
./waf настроить --enable-sudo --enable-modules=lte,fd-net-device --enable-examples

# строить
./ваф

Затем мы настраиваем два виртуальных интерфейса Ethernet и запускаем wireshark для просмотра трафика.
прохождение:

# примечание: вы должны быть root

# создаем два сопряженных устройства veth
IP-ссылка добавить имя veth0 тип veth имя однорангового узла veth1
IP ссылка показать

# включить неразборчивый режим
IP-ссылка включает veth0 promisc
IP-ссылка включает veth1 promisc

# поднять интерфейсы
IP-ссылка установлена ​​​​veth0 вверх
IP-ссылка установлена ​​​​veth1 вверх

# запускаем wireshark и захватываем на veth0
Wireshark &

Теперь мы можем запустить пример программы с симулированными часами:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1"

Используя wireshark, вы должны сначала увидеть разрешение ARP, затем некоторые пакеты GTP обменялись обоими
в восходящей и нисходящей линии связи.

Настройкой по умолчанию для примерной программы является 1 eNB и 1UE. Вы можете изменить это через
параметры командной строки, например:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1 --nEnbs=2 --nUesPerEnb =2"

Чтобы получить список доступных параметров:

./waf --run lena-simple-epc-emu --command="%s --PrintHelp"

Для запуска с часами реального времени: оказывается, отладочная сборка по умолчанию слишком медленная для
в реальном времени. Смягчение ограничений реального времени с помощью режима BestEffort не является хорошей идеей:
что-то может пойти не так (например, может произойти сбой ARP) и, если это так, вы не получите никаких пакетов данных
вне. Итак, вам нужно приличное оборудование и оптимизированная сборка со статически связанным
модули:

./waf настроить -d оптимизировано --enable-static --enable-modules=lte --enable-examples --enable-sudo

Затем запустите пример программы следующим образом:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1 --simulatorImplementationType=ns3::RealtimeSimulatorImpl --ns3::RealtimeSimulatorImpl::SynchronizationMode=HardLimit"

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

Подход, описанный в этом разделе, можно использовать с сетевым устройством любого типа. За
например, [Baldo2014] описывает, как он использовался для запуска эмулированной сети LTE-EPC через
реальная многоуровневая пакетно-оптическая транспортная сеть.

Cеть прикрепление
Как показано в базовом примере в разделе Базовый моделирование программа, подключение UE к
eNodeB выполняется путем вызова LteHelper:: Прикрепить функции.

Есть 2 возможных способа подключения к сети. Первый метод – это "руководство" один,
а у второго больше «Автоматический» смысл в этом. Каждая из них будет освещена
эта секция.

Ручная привязанность
Этот метод использует LteHelper:: Прикрепить упомянутая выше функция. Это был единственный
доступный метод подключения к сети в более ранних версиях модуля LTE. Обычно это
вызывается перед началом симуляции:

lteHelper->Прикрепить (ueDevs, enbDev); // присоединяем одно или несколько UE к одному eNodeB

LteHelper::InstallEnbDevice и LteHelper::InstallUeDevice функции должны быть вызваны
перед присоединением. В моделировании с поддержкой EPC также требуется правильное использование IPv4.
предустановлен в UE.

Этот метод очень прост, но требует, чтобы вы точно знали, какое UE к какому принадлежит.
eNodeB перед началом моделирования. Это может быть сложно, когда начальное положение UE
случайным образом определяется сценарием моделирования.

Можно выбрать расстояние между UE и eNodeB в качестве критерия для выбора
соответствующую ячейку. Это довольно просто (по крайней мере, с точки зрения симулятора) и
иногда практично. Но важно отметить, что иногда расстояние не имеет решающего значения.
единственный верный критерий. Например, направленность антенны eNodeB должна быть
так же считается. Кроме того, следует также учитывать состояние канала,
который может колебаться, если есть эффект затухания или затенения. В таких
случаях подключение к сети не должно основываться только на расстоянии.

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

Автоматический привязанность через Idle Режим ячейка выбор процедуры
Сила принятого сигнала является стандартным критерием, используемым для выбора наилучшего
ячейка для присоединения. Использование этого критерия реализовано в начальный ячейка выбор
процесс, который можно вызвать, вызвав другую версию LteHelper:: Прикрепить
функция, как показано ниже:

lteHelper->Прикрепить (ueDevs); // присоединяем одно или несколько UE к сильнейшей ячейке

Отличие от ручного метода заключается в том, что eNodeB назначения не указывается.
процедура найдет наилучшую соту для UE на основе нескольких критериев, включая
сила принятого сигнала (RSRP).

После вызова метода UE потратит некоторое время на измерение соседних сот,
а затем попытаться прикрепить к лучшему. Подробнее можно узнать в разделе
sec-initial-cell-selection проектной документации.

Важно отметить, что этот метод работает только в моделировании с поддержкой EPC. только LTE
моделирования должны прибегать к ручному методу крепления.

закрыто Абонент В группе
Интересным примером использования начального процесса выбора ячейки является настройка симуляции.
среда с закрытой группой подписчиков (CSG).

Например, определенный eNodeB, обычно уменьшенная версия, такая как фемтосота, может принадлежать
частному владельцу (например, домохозяйству или бизнесу), разрешая доступ только к некоторым UE, которые
были ранее зарегистрированы владельцем. eNodeB и зарегистрированные UE в целом
сформировать КСГ.

Ограничение доступа можно смоделировать, «пометив» членов CSG одной и той же CSG.
Я БЫ. Это делается с помощью атрибутов как в eNodeB, так и в UE, например, с помощью
после LteHelper функции:

// пометить следующие eNodeB идентификатором CSG, равным 1, и включенной индикацией CSG
lteHelper->SetEnbDeviceAttribute("CsgId", UintegerValue (1));
lteHelper->SetEnbDeviceAttribute("CsgIndication", BooleanValue (true));

// пометить одно или несколько UE идентификатором CSG, равным 1
lteHelper->SetUeDeviceAttribute("CsgId", UintegerValue (1));

// устанавливаем eNodeB и UE
NetDeviceContainer csgEnbDevs = lteHelper->InstallEnbDevice (csgEnbNodes);
NetDeviceContainer csgUeDevs = lteHelper->InstallUeDevice (csgUeNodes);

Затем включите процедуру первоначального выбора соты на UE:

lteHelper->Прикрепить (csgUeDevs);

Это необходимо, потому что ограничение CSG работает только с автоматическим методом сети.
насадку, но не ручным методом.

Обратите внимание, что установка индикации CSG для eNodeB как ложной (значение по умолчанию)
отключить ограничение, т. е. любое UE может подключаться к этому eNodeB.

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

1. прямая конфигурация в объекте RRC eNodeB;

2. настройка существующего алгоритма хендовера; а также

3. разработка нового алгоритма передачи обслуживания.

В этом разделе будет рассмотрен только первый метод. Второй метод описан в Автоматический
сдавать вызвать, а третий метод подробно описан в разделе
sec-handover-алгоритм проектной документации.

Непосредственная настройка в eNodeB RRC работает следующим образом. Пользователь начинает с создания нового
LteRrcSap::ReportConfigEutra экземпляр и передать его в Лтеенбррк::Аддуемесрепортконфиг
функция. Функция вернет MeasId (идентификация измерения), который является уникальным
ссылка на конфигурацию в экземпляре eNodeB. Эта функция должна быть вызвана до
начинается симуляция. Конфигурация измерения будет активна во всех UE, подключенных к
eNodeB на протяжении всей симуляции. Во время моделирования пользователь может
захватывать отчеты об измерениях, созданные UE, путем прослушивания существующих
LteEnbRrc::RecvMeasurementReport источник трассировки.

Структура ОтчетКонфигурацияEutra соответствует спецификации 3GPP. Определение
структуру и каждое поле-член можно найти в разделе 6.3.5 [TS36331].

Пример кода, приведенный ниже, настраивает измерение RSRP для события A1 для каждого узла eNodeB в пределах
контейнер дэвы:

Конфигурация LteRrcSap::ReportConfigEutra;
config.eventId = LteRrcSap::ReportConfigEutra::EVENT_A1;
config.threshold1.choice = LteRrcSap::ThresholdEutra::THRESHOLD_RSRP;
config.threshold1.range = 41;
config.triggerQuantity = LteRrcSap::ReportConfigEutra::RSRP;
config.reportInterval = LteRrcSap::ReportConfigEutra::MS480;

станд::вектор measIdList;

NetDeviceContainer::Iterator it;
for (it = devs.Begin(); it != devs.End(); it++)
{
Птр разработчик = * оно;
Птр enbDev = dev->ПолучитьОбъект ();
Птр enbRrc = enbDev->GetRrc();

uint8_t measId = enbRrc->AddUeMeasReportConfig (config);
measIdList.push_back(measId); // запомнить созданный measId

enbRrc->TraceConnect("RecvMeasurementReport",
"контекст",
Обратный вызов (&RecvMeasurementReportCallback));
}

Обратите внимание, что пороговые значения выражаются в виде диапазона. В приведенном выше примере диапазон 41 для RSRP
соответствует -100 дБм. Преобразование из и в формат диапазона происходит из-за Раздела
9.1.4 и 9.1.7 [TS36133]. EutransИзмерениеКартирование класс имеет несколько статических
функции, которые можно использовать для этой цели.

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

аннулировать
RecvMeasurementReportCallback (контекст std::string,
uint64_t имси,
uint16_t идентификатор ячейки,
uint16_t rnti,
LteRrcSap::MeasurementReport measReport);

Этот метод зарегистрирует функцию обратного вызова как потребителя измерений UE. в
случай, когда в моделировании участвует более одного потребителя (например, алгоритм передачи обслуживания),
измерения, предназначенные для других потребителей, также будут захвачены этим обратным вызовом
функция. Пользователи могут использовать MeasId поле, содержащееся внутри
LteRrcSap::MeasurementReport аргумент функции обратного вызова, чтобы указать, какое измерение
конфигурация инициировала отчет.

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

Обратите внимание, что только часть конфигурации отчетов (т.е. LteRrcSap::ReportConfigEutra(возврата на рекламные расходы)
параметр измерений UE открыт для настройки потребителями, в то время как другие части
хранятся скрытыми. Внутричастотное ограничение является основной мотивацией этого API.
решение о реализации:

· есть только один, недвусмысленный и окончательный измерение объект, поэтому нет
нужно его настроить;

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

· количество конфигурация настраивается в другом месте, см. sec-performing-measurements; а также

· измерение пробелы не поддерживаются, т.к. применимы только для межчастотных
настройки;

на основе X2 сдавать
Согласно определению 3GPP, хендовер — это процедура смены обслуживающей соты UE в
ПОДКЛЮЧЕННЫЙ режим. Два eNodeB, участвующих в процессе, обычно называются источник
eNodeB и цель eNodeB.

Чтобы включить выполнение хэндовера на основе X2 в моделировании, есть два
требования, которые должны быть выполнены. Во-первых, в моделировании должен быть включен EPC (см. Evolved
пакет Основные (EPC),).

Во-вторых, между двумя eNodeB должен быть настроен интерфейс X2, который необходимо
сделано явно в программе моделирования:

lteHelper->AddX2Interface (enbNodes);

в котором энбнодес - это Нодконтейнер который содержит два eNodeB, между которыми X2
интерфейс должен быть настроен. Если контейнер имеет более двух eNodeB, функция
создаст интерфейс X2 между каждой парой eNodeB в контейнере.

Наконец, целевой eNodeB должен быть настроен как «открытый» для X2 HANDOVER REQUEST. Каждый
eNodeB открыт по умолчанию, поэтому в большинстве случаев не требуется никаких дополнительных инструкций. Тем не менее, пользователи
может установить для eNodeB значение «закрыто», установив логический атрибут
LteEnbRrc:: АдмитХандоверрекуест в ложный. В качестве примера можно запустить лена-x2-передача
программу и установив атрибут таким образом:

NS_LOG=EpcX2:LteEnbRrc ./waf --run lena-x2-handover --command="%s --ns3::LteEnbRrc::AdmitHandoverRequest=false"

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

Ручная сдавать вызвать
Событие передачи может быть инициировано «вручную» в программе моделирования путем планирования
явное событие передачи. LteHelper объект предоставляет удобный метод для
планирование события передачи. В качестве примера предположим, что ueLteDevs - это
NetDeviceContainer который содержит UE, которое должно быть передано, и что enbLteDevs is
другой NetDeviceContainer который содержит исходный и целевой eNB. Затем, передача
at 0.1s можно запланировать следующим образом:

lteHelper->HandoverRequest (Секунды (0.100),
ueLteDevs.Получить (0),
энбЛтеДевс.Получить (0),
enbLteDevs.Get (1));

Обратите внимание, что UE должно быть уже подключено к исходному eNB, в противном случае симуляция
завершится с сообщением об ошибке.

Пример с полным исходным кодом см. лена-x2-передача пример
программу.

Автоматический сдавать вызвать
Процедура передачи обслуживания также может запускаться «автоматически» обслуживающим eNodeB UE.
Логика триггера зависит от алгоритма передачи обслуживания, активного в данный момент в
Объект RRC eNodeB. Пользователи могут выбирать и настраивать алгоритм передачи обслуживания, который будет использоваться.
в моделировании, которое будет объяснено вкратце в этом разделе. Пользователи также могут выбрать
написать собственную реализацию алгоритма передачи обслуживания, как описано в разделе
sec-handover-алгоритм проектной документации.

Выбор алгоритма хэндовера осуществляется через LteHelper объект и его
SetHandoverAlgorithmType метод, как показано ниже:

Птр lteHelper = СоздатьОбъект ();
lteHelper->SetHandoverAlgorithmType("ns3::A2A4RsrqHandoverAlgorithm");

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

lteHelper->SetHandoverAlgorithmAttribute("ServingCellThreshold",
Uцелое значение (30));
lteHelper->SetHandoverAlgorithmAttribute("NeighbourCellOffset",
Uцелое значение (1));

В модуль LTE включены три варианта алгоритма хендовера. A2-A4-RSRQ
алгоритм передачи (названный как ns3::A2A4RsrqHandoverАлгоритм) является параметром по умолчанию, и
использование уже было показано выше.

Другим вариантом является сильная ячейка алгоритм передачи (названный как
ns3::A3RsrpАлгоритм передачи), который можно выбрать и настроить с помощью следующего кода:

lteHelper->SetHandoverAlgorithmType("ns3::A3RsrpHandoverAlgorithm");
lteHelper->SetHandoverAlgorithmAttribute ("Гистерезис",
Двойное значение (3.0));
lteHelper->SetHandoverAlgorithmAttribute("TimeToTrigger",
TimeValue (миллисекунды (256)));

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

lteHelper->SetHandoverAlgorithmType("ns3::NoOpHandoverAlgorithm");

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

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

NetDeviceContainer enbLteDevs = lteHelper->InstallEnbDevice (enbNodes);

Пример с полным исходным кодом использования триггера автоматического хэндовера можно найти в
Лена-x2-передачи-меры пример программы.

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

Основная причина сбоя хендовера, которую мы будем устранять, — это ошибка при передаче
сигнальные сообщения, связанные с передачей обслуживания, во время выполнения процедуры передачи обслуживания. В качестве
видно из рисунка fig-x2-based-handover-seq-диаграмма из проектной документации,
их много и они используют разные интерфейсы и протоколы. Во имя
простоты, мы можем с уверенностью предположить, что интерфейс X2 (между исходным eNodeB и
целевой eNodeB) и интерфейс S1 (между целевым eNodeB и SGW/PGW) вполне
стабильный. Поэтому мы сосредоточим наше внимание на протоколе RRC (между UE и
eNodeB) и процедура произвольного доступа, которые обычно передаются по воздуху.
и восприимчив к ухудшению состояния канала.

Общие советы по уменьшению ошибок передачи: обеспечивать высокая достаточно SINR уровень в каждом
УЭ. Этого можно добиться путем правильного планирования топологии сети. сводит к минимуму сеть
охват отверстие. Если топология имеет известную дыру в покрытии, то UE следует настроить
не рисковать в том районе.

Другой подход, о котором следует помнить, заключается в том, чтобы избежать поздно передачи. Другими словами, передача
должно произойти до того, как SINR UE станет слишком низким, в противном случае UE может не принять
команда передачи обслуживания от исходного eNodeB. Алгоритмы хендовера позволяют контролировать
насколько рано или поздно принимается решение о передаче. Например, алгоритм передачи обслуживания A2-A4-RSRQ.
можно настроить с более высоким порогом, чтобы он раньше принимал решение о передаче обслуживания. Сходным образом,
меньший гистерезис и/или более короткое время срабатывания в самом сильном алгоритме переключения ячеек
обычно приводит к более ранней передаче. Для того, чтобы найти правильные значения для этих
параметров, одним из факторов, который следует учитывать, является скорость движения UE.
Как правило, более быстро перемещающееся UE требует, чтобы передача обслуживания выполнялась раньше. Некоторые исследования
работы предложили рекомендуемые значения, например, в [Lee2010].

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

Config::SetDefault("ns3::LteSpectrumPhy::CtrlErrorModelEnabled", BooleanValue (false));
Config::SetDefault("ns3::LteSpectrumPhy::DataErrorModelEnabled", BooleanValue (false));

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

Сдавать шаги
Модель RRC, в частности Лтеенбрррк и LteUeRrc объекты, предоставить некоторые полезные
трассировки, которые можно подключить к некоторым пользовательским функциям, чтобы они вызывались при запуске
и конец фазы выполнения передачи обслуживания как на стороне UE, так и на стороне eNB. Например, в
вашей программе моделирования вы можете объявить следующие методы:

аннулировать
NotifyHandoverStartUe (контекст std::string,
uint64_t имси,
uint16_t идентификатор ячейки,
uint16_t rnti,
uint16_t targetCellId)
{
std::cout << Simulator::Now ().GetSeconds () << " " << контекст
<< "УП ИМСИ" << имси
<< ": ранее подключенный к CellId " << cellId
<< "с РНТИ" << рнти
<< ", передача обслуживания CellId " << targetCellId
<< стд::эндл;
}

аннулировать
NotifyHandoverEndOkUe (контекст std::string,
uint64_t имси,
uint16_t идентификатор ячейки,
uint16_t rnti)
{
std::cout << Simulator::Now ().GetSeconds () << " " << контекст
<< "УП ИМСИ" << имси
<< ": успешная передача на CellId " << CellId
<< "с РНТИ" << рнти
<< стд::эндл;
}

аннулировать
NotifyHandoverStartEnb (контекст std::string,
uint64_t имси,
uint16_t идентификатор ячейки,
uint16_t rnti,
uint16_t targetCellId)
{
std::cout << Simulator::Now ().GetSeconds () << " " << контекст
<< " идентификатор ячейки eNB " << идентификатор ячейки
<< ": начать передачу UE с IMSI " << imsi
<< "РНТИ" << рнти
<< " в CellId " << targetCellId
<< стд::эндл;
}

аннулировать
NotifyHandoverEndOkEnb (контекст std::string,
uint64_t имси,
uint16_t идентификатор ячейки,
uint16_t rnti)
{
std::cout << Simulator::Now ().GetSeconds () << " " << контекст
<< " идентификатор ячейки eNB " << идентификатор ячейки
<< ": завершена передача UE с IMSI " << imsi
<< "РНТИ" << рнти
<< стд::эндл;
}

Затем вы можете подключить эти методы к соответствующим источникам трассировки следующим образом:

Config::Connect("/NodeList/*/DeviceList/*/LteEnbRrc/HandoverStart",
Обратный звонок (&NotifyHandoverStartEnb));
Config::Connect("/NodeList/*/DeviceList/*/LteUeRrc/HandoverStart",
Обратный звонок (&NotifyHandoverStartUe));
Config::Connect("/NodeList/*/DeviceList/*/LteEnbRrc/HandoverEndOk",
Обратный звонок (&NotifyHandoverEndOkEnb));
Config::Connect("/NodeList/*/DeviceList/*/LteUeRrc/HandoverEndOk",
Обратный звонок (&NotifyHandoverEndOkUe));

Пример программы src/lte/examples/lena-x2-handover.cc иллюстрирует, как все вышеперечисленное
инструкции могут быть интегрированы в программу моделирования. Вы можете запустить программу следующим образом:

./waf --run лена-x2-передача

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

NS_LOG=LteEnbRrc:LteUeRrc:EpcX2 ./waf --run lena-x2-handover

частота Снова использовать Алгоритмы
В этом разделе мы опишем, как использовать алгоритмы повторного использования частоты в eNb в рамках LTE.
симуляции. Возможны два варианта конфигурации. Первый подход – это
«ручной», он требует настройки большего количества параметров, но позволяет пользователю настраивать FR
алгоритм, который ему нужен. Второй подход более «автоматический». Это очень удобно,
потому что он одинаков для каждого алгоритма FR, поэтому пользователь может очень быстро переключать алгоритм FR,
изменение только типа алгоритма FR. Одним из недостатков является то, что «автоматический» подход использует только
ограниченный набор конфигураций для каждого алгоритма, что делает его менее гибким, но
достаточно для большинства случаев.

Эти два подхода будут описаны более подробно в следующем подразделе.

Если пользователь не настраивает алгоритм повторного использования частоты, используется алгоритм по умолчанию (например, LteFrNoOpAlgorithm).
установлен в eNb. Это действует так, как если бы алгоритм FR был отключен.

Следует отметить, что большинство реализованных алгоритмов FR работают с
пропускная способность соты больше или равна 15 RB. Это ограничение вызвано требованием, чтобы
UE для передачи должны быть назначены по меньшей мере три непрерывных RB.

Ручная конфигурация
Алгоритм повторного использования частот можно настроить «вручную» в программе моделирования с помощью
установка типа алгоритма FR и всех его атрибутов. В настоящее время существует семь алгоритмов FR.
реализовано:

· ns3::LteFrNoOpAlgorithm

· ns3::LteFrHardAlgorithm

· ns3::LteFrStrictAlgorithm

· ns3::LteFrSoftAlgorithm

· ns3::LteFfrSoftAlgorithm

· ns3::LteFfrEnhancedAlgorithm

· ns3::LteFfrDistributedAlgorithm

Выбор алгоритма FR осуществляется через LteHelper объект и его SetFfrAlgorithmType
метод, как показано ниже:

Птр lteHelper = СоздатьОбъект ();
lteHelper->SetFfrAlgorithmType("ns3::LteFrHardAlgorithm");

Каждый реализованный алгоритм FR предоставляет несколько настраиваемых атрибутов. У пользователей нет
заботиться о конфигурации пропускной способности UL и DL, потому что это делается автоматически во время
конфигурация ячейки. Чтобы изменить пропускную способность для алгоритма FR, настройте необходимые значения для
Лтеенбнетдевице:

пропускная способность uint8_t = 100;
lteHelper->SetEnbDeviceAttribute("DlBandwidth", UintegerValue (пропускная способность));
lteHelper->SetEnbDeviceAttribute("UlBandwidth", UintegerValue (пропускная способность));

Теперь будет описана конфигурация каждого алгоритма FR.

Жесткий частота Снова использовать Алгоритм
Как описано в разделе sec-fr-hard-algorithm конструкторской документации.
ns3::LteFrHardAlgorithm использует один поддиапазон. Для настройки этого поддиапазона пользователю необходимо указать
смещение и пропускная способность для DL и UL в количестве RB.

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

· Длсуббандоффсет: Смещение нисходящей линии связи в количестве групп блоков ресурсов

· Пропускная способность DlSub: Конфигурация поддиапазона передачи по нисходящему каналу в количестве
Группы блоков ресурсов

· UlSubBandOffset: Смещение восходящей линии связи в количестве групп блоков ресурсов

· UlSubПропускная способность: Конфигурация подполосы передачи восходящего канала в количестве ресурсов
Группы блоков

Пример настройки LteFrHardAlgorithm можно выполнить следующим образом:

lteHelper->SetFfrAlgorithmType("ns3::LteFrHardAlgorithm");
lteHelper->SetFfrAlgorithmAttribute("DlSubBandOffset", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute("DlSubBandwidth", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute("UlSubBandOffset", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute("UlSubBandwidth", UintegerValue (8));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

Приведенный выше пример позволяет eNB использовать только RB с 8 по 16 в DL и UL, в то время как вся ячейка
пропускная способность 25.

Строгий частота Снова использовать Алгоритм
Алгоритм строгого повторного использования частот использует два поддиапазона: один общий для каждой соты и один
частный. Существует также пороговое значение RSRQ, которое необходимо для принятия решения о том, в каком поддиапазоне находится UE.
следует подавать. Причем мощность передачи в этих поддиапазонах может быть разной.

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

· UlCommonSubПропускная способность: Конфигурация общей подполосы восходящего канала в количестве ресурсов
Группы блоков

· UlEdgeSubBandOffset: Смещение поддиапазона края восходящей линии связи в количестве групп блоков ресурсов

· UlEdgeSubПропускная способность: Конфигурация SubBandwidth Edge восходящей линии связи в количестве ресурсов
Группы блоков

· Пропускная способность DlCommonSub: Конфигурация общей подполосы нисходящей линии связи в количестве
Группы блоков ресурсов

· Дледжесуббандоффсет: Смещение поддиапазона края нисходящей линии связи в количестве групп блоков ресурсов

· Пропускная способность DlEdgeSub: Конфигурация SubBandwidth Edge нисходящей линии связи в количестве ресурсов
Группы блоков

· Рсркпорог: Если RSRQ хуже этого порога, UE следует обслуживать в
крайний поддиапазон

· ЦентрПауэрСмещение: Значение PdschConfigDedicated::Pa для центрального поддиапазона, значение по умолчанию
dB0

· EdgePowerOffset: Значение PdschConfigDedicated::Pa для граничного поддиапазона, значение по умолчанию dB0

· ЦентрОбластьTpc: значение TPC, которое будет установлено в DL-DCI для UE в центральной области, абсолютное
используется режим, значение по умолчанию 1 отображается на -1 в соответствии с таблицей 36.213-5.1.1.1 TS2.

· EdgeAreaTpc: значение TPC, которое будет установлено в DL-DCI для UE в пограничной области, абсолютное
используется режим, значение по умолчанию 1 отображается на -1 в соответствии с таблицей 36.213-5.1.1.1 TS2.

Пример ниже позволяет eNB использовать RB от 0 до 6 в качестве общего поддиапазона и от 12 до 18 в качестве
частный поддиапазон в DL и UL, порог RSRQ составляет 20 дБ, мощность в центральной области равна
LteEnbPhy::TxPower - 3dB, мощность в краевой области равна LteEnbPhy::TxPower + 3dB:

lteHelper->SetFfrAlgorithmType("ns3::LteFrStrictAlgorithm");
lteHelper->SetFfrAlgorithmAttribute("DlCommonSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute("UlCommonSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute("DlEdgeSubBandOffset", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute("DlEdgeSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute("UlEdgeSubBandOffset", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute("UlEdgeSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute("RsrqThreshold", UintegerValue (20));
lteHelper->SetFfrAlgorithmAttribute("CenterPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB_3));
lteHelper->SetFfrAlgorithmAttribute("EdgePowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB3));
lteHelper->SetFfrAlgorithmAttribute("CenterAreaTpc", UintegerValue (1));
lteHelper->SetFfrAlgorithmAttribute("EdgeAreaTpc", UintegerValue (2));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

мягкая частота Снова использовать Алгоритм
С алгоритмом мягкого повторного использования частоты eNb использует всю полосу пропускания соты, но есть два
поддиапазоны внутри UE обслуживаются с разным уровнем мощности.

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

· UlEdgeSubBandOffset: Смещение поддиапазона края восходящей линии связи в количестве групп блоков ресурсов

· UlEdgeSubПропускная способность: Конфигурация SubBandwidth Edge восходящей линии связи в количестве ресурсов
Группы блоков

· Дледжесуббандоффсет: Смещение поддиапазона края нисходящей линии связи в количестве групп блоков ресурсов

· Пропускная способность DlEdgeSub: Конфигурация SubBandwidth Edge нисходящей линии связи в количестве ресурсов
Группы блоков

· Алловцентруеуседжеджеподдиапазон: Если истинно центральные UE могут принимать на краевом поддиапазоне RBG,
в противном случае граничный поддиапазон разрешен только для граничных UE, значение по умолчанию равно true

· Рсркпорог: Если RSRQ хуже этого порога, UE следует обслуживать в
крайний поддиапазон

· ЦентрПауэрСмещение: Значение PdschConfigDedicated::Pa для центрального поддиапазона, значение по умолчанию
dB0

· EdgePowerOffset: Значение PdschConfigDedicated::Pa для граничного поддиапазона, значение по умолчанию dB0

· ЦентрОбластьTpc: значение TPC, которое будет установлено в DL-DCI для UE в центральной области, абсолютное
используется режим, значение по умолчанию 1 отображается на -1 в соответствии с таблицей 36.213-5.1.1.1 TS2.

· EdgeAreaTpc: значение TPC, которое будет установлено в DL-DCI для UE в пограничной области, абсолютное
используется режим, значение по умолчанию 1 отображается на -1 в соответствии с таблицей 36.213-5.1.1.1 TS2.

Пример ниже конфигурирует RB от 8 до 16 для использования UE на границе соты, и этот поддиапазон
недоступен для пользователей сотового центра. Порог RSRQ составляет 20 дБ, мощность в центральной области равна
LteEnbPhy::TxPower, мощность в краевой области равна LteEnbPhy::TxPower + 3dB:

lteHelper->SetFfrAlgorithmType("ns3::LteFrSoftAlgorithm");
lteHelper->SetFfrAlgorithmAttribute("DlEdgeSubBandOffset", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute("DlEdgeSubBandwidth", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute("UlEdgeSubBandOffset", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute("UlEdgeSubBandwidth", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute("AllowCenterUeUseEdgeSubBand", BooleanValue (false));
lteHelper->SetFfrAlgorithmAttribute("RsrqThreshold", UintegerValue (20));
lteHelper->SetFfrAlgorithmAttribute("CenterPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB0));
lteHelper->SetFfrAlgorithmAttribute("EdgePowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB3));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

мягкая дробный частота Снова использовать Алгоритм
Мягкое дробное повторное использование частот (SFFR) использует три поддиапазона: центральный, средний (общий) и
край. Пользователю необходимо настроить только два из них: общий и пограничный. Центральный поддиапазон будет
составленный из оставшейся полосы пропускания. Каждый поддиапазон может обслуживаться разными
мощность передачи. Поскольку имеется три поддиапазона, необходимо задать два пороговых значения RSRQ.
сконфигурировано.

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

· UlCommonSubПропускная способность: Конфигурация общей подполосы восходящего канала в количестве ресурсов
Группы блоков

· UlEdgeSubBandOffset: Смещение поддиапазона края восходящей линии связи в количестве групп блоков ресурсов

· UlEdgeSubПропускная способность: Конфигурация SubBandwidth Edge восходящей линии связи в количестве ресурсов
Группы блоков

· Пропускная способность DlCommonSub: Конфигурация общей подполосы нисходящей линии связи в количестве
Группы блоков ресурсов

· Дледжесуббандоффсет: Смещение поддиапазона края нисходящей линии связи в количестве групп блоков ресурсов

· Пропускная способность DlEdgeSub: Конфигурация SubBandwidth Edge нисходящей линии связи в количестве ресурсов
Группы блоков

· Центррсркпорог: Если RSRQ хуже этого порога, UE следует обслуживать
в среднем поддиапазоне

· EdgeRsrqПороговое значение: Если RSRQ хуже этого порога, UE следует обслуживать
в краевом поддиапазоне

· ЦентрОбластьМощностьСмещение: Значение PdschConfigDedicated::Pa для центрального поддиапазона, по умолчанию
значение дБ0

· MediumAreaPowerOffset: Значение PdschConfigDedicated::Pa для среднего поддиапазона, по умолчанию
значение дБ0

· EdgeAreaPowerOffset: Значение PdschConfigDedicated::Pa для граничного поддиапазона, значение по умолчанию
dB0

· ЦентрОбластьTpc: значение TPC, которое будет установлено в DL-DCI для UE в центральной области, абсолютное
используется режим, значение по умолчанию 1 отображается на -1 в соответствии с таблицей 36.213-5.1.1.1 TS2.

· СредняяОбластьTpc: значение TPC, которое будет установлено в DL-DCI для UE в средней зоне, абсолютное
используется режим, значение по умолчанию 1 отображается на -1 в соответствии с таблицей 36.213-5.1.1.1 TS2.

· EdgeAreaTpc: значение TPC, которое будет установлено в DL-DCI для UE в пограничной области, абсолютное
используется режим, значение по умолчанию 1 отображается на -1 в соответствии с таблицей 36.213-5.1.1.1 TS2.

В приведенном ниже примере RB от 0 до 6 будут использоваться как общий (средний) поддиапазон, RB от 6 до
12 будет использоваться в качестве краевого поддиапазона, а RB с 12 по 24 будет использоваться в качестве центрального поддиапазона (это
состоит из оставшихся RB). Порог RSRQ между центром и средней зоной составляет 28 дБ,
Порог RSRQ между средней и краевой зонами составляет 18 дБ. Мощность в центре равна
LteEnbPhy::TxPower - 3dB, мощность в средней площади равна LteEnbPhy::TxPower + 3dB, мощность в
площадь края равна LteEnbPhy::TxPower + 3dB:

lteHelper->SetFfrAlgorithmType("ns3::LteFfrSoftAlgorithm");
lteHelper->SetFfrAlgorithmAttribute("UlCommonSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute("DlCommonSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute("DlEdgeSubBandOffset", UintegerValue (0));
lteHelper->SetFfrAlgorithmAttribute("DlEdgeSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute("UlEdgeSubBandOffset", UintegerValue (0));
lteHelper->SetFfrAlgorithmAttribute("UlEdgeSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute("CenterRsrqThreshold", UintegerValue (28));
lteHelper->SetFfrAlgorithmAttribute("EdgeRsrqThreshold", UintegerValue (18));
lteHelper->SetFfrAlgorithmAttribute("CenterAreaPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB_3));
lteHelper->SetFfrAlgorithmAttribute("MediumAreaPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB0));
lteHelper->SetFfrAlgorithmAttribute("EdgeAreaPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB3));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

Повышенная дробный частота Снова использовать Алгоритм
Enhanced Fractional Frequency Reuse (EFFR) резервирует часть пропускной способности системы для каждой соты.
(обычно существует 3 типа ячеек, и каждая из них получает 1/3 пропускной способности системы). Затем часть
этот поддиапазон он использовал как первичная Segment с коэффициентом повторного использования 3 и как Старшая школа Segment
с коэффициентом повторного использования 1. Пользователь должен настроить (для DL и UL) смещение полосы пропускания соты
в количестве РБ, номер РБ, который будет использоваться как первичная Segment и количество РБ, которое
будет использоваться как Старшая школа Segment. первичная Segment используется клеткой по желанию, но РБ из
Старшая школа Segment может быть назначено UE только в том случае, если обратная связь CQI от этого UE имеет более высокий
значение, чем настроенное пороговое значение CQI. UE считается граничным UE, когда его RSRQ ниже
чем Рсркпорог.

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

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

· UlSubBandOffset: Смещение поддиапазона восходящей линии связи для этой соты в количестве блоков ресурсов
Группы

· UlReuse3SubПропускная способность: Конфигурация повторного использования 3 поддиапазона восходящей линии связи в количестве ресурсов
Группы блоков

· UlReuse1SubПропускная способность: Конфигурация повторного использования 1 поддиапазона восходящей линии связи в количестве ресурсов
Группы блоков

· Длсуббандоффсет: Смещение поддиапазона нисходящей линии связи для этой соты в количестве блоков ресурсов
Группы

· Пропускная способность DlReuse3Sub: Конфигурация SubBandwidth SubBandwidth Reuse 3 нисходящего канала в количестве
Группы блоков ресурсов

· Пропускная способность DlReuse1Sub: Конфигурация SubBandwidth SubBandwidth Reuse 1 нисходящего канала в количестве
Группы блоков ресурсов

· Рсркпорог: Если RSRQ хуже этого порога, UE следует обслуживать в
крайний поддиапазон

· ЦентрОбластьМощностьСмещение: Значение PdschConfigDedicated::Pa для центрального поддиапазона, по умолчанию
значение дБ0

· EdgeAreaPowerOffset: Значение PdschConfigDedicated::Pa для граничного поддиапазона, значение по умолчанию
dB0

· DlCqiПорог: Если DL-CQI для RBG выше этого порога, передача
на РБГ можно

· UlCqiПорог: Если UL-CQI для RBG выше этого порога, передача
на РБГ можно

· ЦентрОбластьTpc: значение TPC, которое будет установлено в DL-DCI для UE в центральной области, абсолютное
используется режим, значение по умолчанию 1 отображается на -1 в соответствии с таблицей 36.213-5.1.1.1 TS2.

· EdgeAreaTpc: значение TPC, которое будет установлено в DL-DCI для UE в пограничной области, абсолютное
используется режим, значение по умолчанию 1 отображается на -1 в соответствии с таблицей 36.213-5.1.1.1 TS2.

В приведенном ниже примере смещение в DL и UL равно 0 RB, 4 RB будет использоваться в первичная Segment и
Старшая школа Segment. Пороговое значение RSRQ между центром и краевой зоной составляет 25 дБ. DL и UL CQI
пороги установлены на значение 10. Мощность в центральной области равна LteEnbPhy::TxPower - 6dB,
мощность в краевой области равна LteEnbPhy::TxPower + 0dB:

lteHelper->SetFfrAlgorithmType("ns3::LteFfrEnhancedAlgorithm");
lteHelper->SetFfrAlgorithmAttribute("RsrqThreshold", UintegerValue (25));
lteHelper->SetFfrAlgorithmAttribute("DlCqiThreshold", UintegerValue (10));
lteHelper->SetFfrAlgorithmAttribute("UlCqiThreshold", UintegerValue (10));
lteHelper->SetFfrAlgorithmAttribute("CenterAreaPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB_6));
lteHelper->SetFfrAlgorithmAttribute("EdgeAreaPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB0));
lteHelper->SetFfrAlgorithmAttribute("UlSubBandOffset", UintegerValue (0));
lteHelper->SetFfrAlgorithmAttribute("UlReuse3SubBandwidth", UintegerValue (4));
lteHelper->SetFfrAlgorithmAttribute("UlReuse1SubBandwidth", UintegerValue (4));
lteHelper->SetFfrAlgorithmAttribute("DlSubBandOffset", UintegerValue (0));
lteHelper->SetFfrAlgorithmAttribute("DlReuse3SubBandwidth", UintegerValue (4));
lteHelper->SetFfrAlgorithmAttribute("DlReuse1SubBandwidth", UintegerValue (4));

Распределенный дробный частота Снова использовать Алгоритм
Распределенное повторное использование дробной частоты требует наличия интерфейса X2 между всеми eNB.
установлены. Интерфейсы X2 можно установить только при настроенном EPC, поэтому эта схема FFR
можно использовать только со сценариями EPC.

Благодаря алгоритму повторного использования распределенной дробной частоты eNb использует всю полосу пропускания соты и
может быть два поддиапазона: центральный поддиапазон и краевой поддиапазон. В этих поддиапазонах UE
можно подавать с разным уровнем мощности. Алгоритм адаптивно выбирает RB для края ячейки
поддиапазон на основе информации о координации (т. е. RNTP) от соседних сот и уведомляет
базовые станции соседних сот, которые он выбрал для использования в краевом поддиапазоне. Если
в соте нет UE, классифицированного как граничное UE, eNB не будет использовать какие-либо RB в качестве граничного поддиапазона.

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

· РасчетИнтервал: Интервал времени между расчетами поддиапазона Edge, по умолчанию
значение 1 секунда

· Рсркпорог: Если RSRQ хуже этого порога, UE следует обслуживать в
крайний поддиапазон

· Рсрпдифференспорог: Если разница между мощностью принимаемого сигнала
на UE из обслуживающей соты и мощность сигнала, принятого из соседней
ячейка меньше значения RsrpDifferenceThreshold, вес ячейки увеличивается

· ЦентрПауэрСмещение: Значение PdschConfigDedicated::Pa для граничного поддиапазона, значение по умолчанию
dB0

· EdgePowerOffset: Значение PdschConfigDedicated::Pa для граничного поддиапазона, значение по умолчанию dB0

· EdgeRbNum: Количество RB, которые можно использовать в краевом поддиапазоне.

· ЦентрОбластьTpc: значение TPC, которое будет установлено в DL-DCI для UE в центральной области, абсолютное
используется режим, значение по умолчанию 1 отображается на -1 в соответствии с таблицей 36.213-5.1.1.1 TS2.

· EdgeAreaTpc: значение TPC, которое будет установлено в DL-DCI для UE в пограничной области, абсолютное
используется режим, значение по умолчанию 1 отображается на -1 в соответствии с таблицей 36.213-5.1.1.1 TS2.

В приведенном ниже примере интервал расчета составляет 500 мс. Порог RSRQ между центром и краем
25. Порог различия RSRP установлен равным 5. В DL и UL 6 RB будет использоваться
каждой ячейке в краевом поддиапазоне. Мощность в центре равна LteEnbPhy::TxPower - 0dB, мощность
в области края равно LteEnbPhy::TxPower + 3dB:

lteHelper->SetFfrAlgorithmType("ns3::LteFfrDistributedAlgorithm");
lteHelper->SetFfrAlgorithmAttribute("Интервал расчета", TimeValue(Миллисекунды(500)));
lteHelper->SetFfrAlgorithmAttribute("RsrqThreshold", UintegerValue (25));
lteHelper->SetFfrAlgorithmAttribute("RsrpDifferenceThreshold", UintegerValue (5));
lteHelper->SetFfrAlgorithmAttribute("EdgeRbNum", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute("CenterPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB0));
lteHelper->SetFfrAlgorithmAttribute("EdgePowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB3));

Автоматический конфигурация
Алгоритмы повторного использования частоты также можно настроить более «автоматически», установив только
пропускная способность и FrCellTypeId. Во время инициализации экземпляра FR конфигурация для
установите пропускную способность и FrCellTypeId будут взяты из таблицы конфигурации. Это важно
что будут настроены только поддиапазоны, пороги и мощность передачи будут установлены на
значения по умолчанию. Если кто-то хочет, он / она может изменить пороги и мощность передачи, как показано на рисунке.
в предыдущем подразделе.

Есть три FrCellTypeId: 1, 2, 3, которые соответствуют трем различным конфигурациям
для каждой полосы пропускания. Три конфигурации позволяют иметь различные конфигурации в
соседние ячейки в шестиугольной компоновке eNB. Если пользователю нужно иметь больше различных
конфигурации для соседних сот, ему/ей необходимо использовать ручную настройку.

Пример ниже показывает автоматическую настройку алгоритма FR:

lteHelper->SetFfrAlgorithmType("ns3::LteFfrSoftAlgorithm");
lteHelper->SetFfrAlgorithmAttribute("FrCellTypeId", UintegerValue (1));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

Хакеры: Запитан Контролировать
Функция управления мощностью восходящего канала включена по умолчанию. Пользователь может отключить его, установив
логический атрибут ns3::LteUePhy::EnableUplinkPowerControl к истине.

Пользователь может переключаться между механизмами управления мощностью с разомкнутым контуром и механизмом управления мощностью с замкнутым контуром.
установив логический атрибут ns3::LteUePowerControl::ClosedLoop. По умолчанию закрыто
Включено управление мощностью контура с режимом накопления.

Потеря пути является ключевым компонентом управления мощностью восходящей линии связи. Он рассчитывается как разница между
отфильтрованные параметры RSRP и ReferenceSignalPower. ReferenceSignalPower отправляется с SIB2.

Атрибуты, доступные в Uplink Power Control:

· замкнутый цикл: если true, то включен режим управления мощностью восходящего канала с обратной связью и открытая петля.
Управление питанием, в противном случае значение по умолчанию — false.

· Аккумулянтенаблед: если true Режим накопления включен и Абсолютный режим
в противном случае значение по умолчанию равно false

· Альфа: коэффициент компенсации потерь в тракте, значение по умолчанию 1.0.

· Пкмин: минимальная мощность TxPower UE, значение по умолчанию -40 дБм

· Pcмакс: максимальная мощность TxPower UE, значение по умолчанию 23 дБм

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

· PoUePush: этот параметр должен устанавливаться более высокими уровнями, но в настоящее время он должен
настраивается системой атрибутов, возможные значения — целые числа в диапазоне (-8 ... 7),
Значение по умолчанию - 0.

· Псрсофсет: этот параметр должен устанавливаться более высокими уровнями, но в настоящее время он должен
настраивается системой атрибутов, возможные значения — целые числа в диапазоне (0 ... 15),
Значение по умолчанию равно 7, что дает P_Srs_Offset_Value = 0

Проследить ценности in Хакеры: Запитан Контроль:

· ОтчетPushTxPower: Текущая мощность TxPower UE для PUSCH

· СообщитьPucchTxPower: Текущая мощность TxPower UE для PUCCH

· СообщитьSrsTxPower: Текущая мощность TxPower UE для SRS

Пример конфигурации представлен ниже:

Config::SetDefault("ns3::LteUePhy::EnableUplinkPowerControl", BooleanValue (true));
Config::SetDefault("ns3::LteEnbPhy::TxPower", DoubleValue (30));
Config::SetDefault("ns3::LteUePowerControl::ClosedLoop", BooleanValue (true));
Config::SetDefault("ns3::LteUePowerControl::AccumulationEnabled", BooleanValue (true));

Например, пользователь может посмотреть и запустить программу lena-uplink-power-control.

Примеры Программы
Каталог src/lte/примеры/ содержит несколько примеров программ моделирования, которые показывают, как
моделировать различные сценарии LTE.

Референции Сценарии
Существует огромное количество эталонных сценариев моделирования LTE, которые можно найти в
литература. Здесь мы перечислим некоторые из них:

· Сценарии моделирования системы, упомянутые в разделе A.2 [TR36814].

· Двухполосная модель [R4-092042], частично реализованная в примере
программа src/lte/examples/lena-dual-stripe.cc. В этом примере программы много
настраиваемые параметры, которые можно настроить, изменив соответствующий глобальный
переменные. Чтобы получить список всех этих глобальных переменных, вы можете запустить эту команду:

./waf --run lena-dual-stripe --command-template="%s --PrintGlobals"

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

Сдавать моделирование кампании
В этом подразделе мы продемонстрируем пример запуска имитационной кампании с использованием
модуль LTE нс-3. Цель кампании — сравнить эффект каждого
встроенный алгоритм хендовера модуля LTE.

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

Количество хэндоверов можно получить, подсчитав, сколько раз ПередачаКонецОк
Сдавать шаги уволен. Затем можно получить среднюю пропускную способность пользователя, включив
RLC Симуляторы Результат. Наконец, SINR можно получить, включив симуляцию PHY.
выход. В следующем примере кода показан один из возможных способов получения вышеуказанного:

аннулировать
NotifyHandoverEndOkUe (std::string context, uint64_t imsi,
uint16_t идентификатор ячейки, uint16_t rnti)
{
std::cout << "Передача IMSI" << imsi << std::endl;
}

Int
main (int argc, char * argv [])
{
/*** СНИП ***/

Config::Connect("/NodeList/*/DeviceList/*/LteUeRrc/HandoverEndOk",
Обратный звонок (&NotifyHandoverEndOkUe));

lteHelper->EnablePhyTraces ();
lteHelper->ВключитьRlcTraces ();
Птр rlcStats = lteHelper->GetRlcStats ();
rlcStats->SetAttribute("StartTime", TimeValue(Seconds (0)));
rlcStats->SetAttribute("EpochDuration", TimeValue(Seconds (simTime)));

Симулятор :: Беги ();
Симулятор :: Уничтожить ();
0 вернуться;
}

Затем мы должны настроить параметры программы в соответствии с потребностями моделирования. Мы
ищем следующие предположения в нашем моделировании:

· 7 узлов трехсекторных макроэлементов eNodeB (т. е. 21 макроячейка), развернутых в шестиугольной
планировка с межучастковым расстоянием 500 м.

· Несмотря на то что лена-двойная полоса изначально предназначен для двухъярусной (макроячейка и
фемтосота), мы упростим нашу симуляцию до одноуровневой (макросоты)
только симуляция.

· Пользовательские устройства случайным образом распределяются по площадкам и автоматически подключаются к сети.
с помощью выбора ячейки в режиме ожидания. После этого UE будет перемещаться по среде моделирования.
со скоростью движения 60 км/ч.

· Продолжительность симуляции 50 секунд, так что UE прошли бы достаточно далеко, чтобы вызвать некоторые
передачи.

· Мощность передатчика макроячейки 46 дБм и мощность передатчика UE 10 дБм.

· Будет использоваться режим EPC, поскольку процедура передачи обслуживания X2 требует его включения.

· Полная буферизация нисходящего и восходящего трафика с полосой пропускания 5 МГц с использованием протокола TCP.
планировщик Proportional Fair.

· Идеальный протокол RRC.

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

лена-двойная полоса параметр конфигурация для сдавать кампании
┌ackим определителю ───────┐
│Название параметра │ Значение │ Описание │
├ackим определителю ───────┤
│simTime │ 50 │ Симуляция 50 секунд │
│ │ │ продолжительность │
├ackим определителю ───────┤
│nБлоков │ 0 │ Отключение квартиры │
│ │ │ здания и фемтосоты │
├ackим определителю ───────┤
│nMacroEnbSites │ 7 │ Количество макроячеек │
│ │ │ сайты (на каждом сайте по 3 │
│ │ │ клетки) │
├ackим определителю ───────┤
│nMacroEnbSitesX │ 2 │ Сайты макроячейки будут │
│ │ │ располагаться по схеме 2-3-2 │
│ │ │ формирование │
├ackим определителю ───────┤
│interSiteDistance │ 500 │ 500 м расстояние между │
│ │ │ соседние участки макроячейки │
├ackим определителю ───────┤
│macroEnbTxPowerDbm │ 46 │ 46 дБм Мощность передачи для каждого │
│ │ │ макроячейка │
├ackим определителю ───────┤
│epc │ 1 │ Включить режим EPC │
└ackим определителю ───────┘

│epcDl │ 1 │ Включить DL с полным буфером │
│ │ │ трафик │
├ackим определителю ───────┤
│epcUl │ 1 │ Включить UL с полным буфером │
│ │ │ трафик │
├ackим определителю ───────┤
│useUdp │ 0 │ Отключить UDP-трафик и │
│ │ │ вместо этого включить TCP │
├ackим определителю ───────┤
│macroUeDensity │ 0.00002 │ Определяет количество UE │
│ │ │ (переводится как 48 UE в │
│ │ │ наша симуляция) │
├ackим определителю ───────┤
│outdoorUeMinSpeed ​​│ 16.6667 │ Минимальное движение UE │
│ │ │ скорость в м/с (60 км/ч) │
├ackим определителю ───────┤
│outdoorUeMaxSpeed ​​│ 16.6667 │ Максимальное движение UE │
│ │ │ скорость в м/с (60 км/ч) │
├ackим определителю ───────┤
│macroEnbBandwidth │ 25 │ 5 МГц DL и UL │
│ │ │ пропускная способность │
├ackим определителю ───────┤
│generateRem │ 1 │ (Необязательно) Для построения графика │
│ │ │ Радиосреда │
│ │ │ Карта │
└ackим определителю ───────┘

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

Переопределение по умолчанию Атрибуты для сдавать кампании
┌ackим определителю ─диимобилил ──────────────┐
├ackим определителю ─диимобилил ──────────────┤
│ns3::LteHelper::HandoverAlgorithm │ ns3::NoOpHandoverAlgorithm, │ Выбор передачи │
│ │ ns3::A3RsrpАлгоритм передачи, │ алгоритм │
│ │ ns3::A2A4RsrqHandoverАлгоритм │ │
├ackим определителю ─диимобилил ──────────────┤
│ns3::LteHelper::Планировщик │ ns3::PfFfMacScheduler │ Пропорциональная справедливость │
├ackим определителю ─диимобилил ──────────────┤
├ackим определителю ─диимобилил ──────────────┤
│ns3::RadioBearerStatsCalculator::DlRlcOutputFilename │ -DlRlcStats.txt │ Имя файла для DL RLC │
├ackим определителю ─диимобилил ──────────────┤
│ns3::RadioBearerStatsCalculator::UlRlcOutputFilename │ -UlRlcStats.txt │ Имя файла для UL RLC │
├ackим определителю ─диимобилил ──────────────┤
│ns3::PhyStatsCalculator::DlRsrpSinrFilename │ -DlRsrpSinrStats.txt │ Имя файла для DL PHY │
├ackим определителю ─диимобилил ──────────────┤
│ns3::PhyStatsCalculator::UlSinrFilename │ -UlSinrStats.txt │ Имя файла для UL PHY │
└ackим определителю ─диимобилил ──────────────┘

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

$ ./waf --run="lena-dual-stripe
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::NoOpHandoverAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=no-op-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=no-op-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=no-op-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=no-op-UlSinrStats.txt
--RngRun=1" > no-op.txt

$ ./waf --run="lena-dual-stripe
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::A3RsrpHandoverAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=a3-rsrp-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=a3-rsrp-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=a3-rsrp-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=a3-rsrp-UlSinrStats.txt
--RngRun=1" > a3-rsrp.txt

$ ./waf --run="lena-dual-stripe
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::A2A4RsrqHandoverAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=a2-a4-rsrq-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=a2-a4-rsrq-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=a2-a4-rsrq-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=a2-a4-rsrq-UlSinrStats.txt
--RngRun=1" > a2-a4-rsrq.txt

Несколько замечаний по исполнению:

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

· Обратите внимание на имена файлов выходных данных симуляции, например, трассировки RLC и трассировки PHY, потому что мы
должны убедиться, что они не будут перезаписаны при следующем запуске моделирования. В этом
Например, мы указываем имена одно за другим, используя аргументы командной строки.

· The --RngRun=1 аргумент в конце используется для установки номера запуска, используемого
Генератор случайных чисел, используемый в моделировании. Мы повторно запускаем те же симуляции с
различный РнгРун значений, тем самым создавая несколько независимых репликаций одного и того же
симуляции. Затем мы усредняем результаты, полученные от этих повторений, чтобы получить
некоторую статистическую достоверность.

· Мы можем добавить --generateRem=1 аргумент для генерации файлов, необходимых для генерации
Карта радиосреды (REM) моделирования. Результат: рисунок REM полученный
от a моделирование in сдавать кампании ниже, которые можно получить, следуя
действия, описанные в разделе Радио Окружающая среда Карты. На этом рисунке также показаны
положение eNodeB и UE в начале моделирования с использованием РнгРун = 1, Другие
значения РнгРун может создавать различные позиции UE.
[изображение] REM, полученный в результате моделирования кампании по передаче. UNINDENT

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

В этом примере мы используем GNU Octave для обработки данных о пропускной способности и SINR.
как показано в примере сценария GNU Octave ниже:

%RxBytes — 10-й столбец
DlRxBytes = load ("no-op-DlRlcStats.txt") (:,10);
DlAverageThroughputKbps = сумма (DlRxBytes) * 8/1000/50

%RxBytes — 10-й столбец
UlRxBytes = load ("no-op-UlRlcStats.txt") (:,10);
UlAverageThroughputKbps = сумма (UlRxBytes) * 8/1000/50

%Sinr — 6-й столбец
DlSinr = load ("no-op-DlRsrpSinrStats.txt") (:,6);
% устранить значения NaN
idx = иснан (DlSinr);
ДлСинр (idx) = 0;
DlAverageSinrDb = 10 * log10 (среднее значение (DlSinr)) % конвертировать в дБ

%Sinr — 5-й столбец
UlSinr = load ("no-op-UlSinrStats.txt") (:,5);
% устранить значения NaN
idx = иснан (UlSinr);
УлСинр (idx) = 0;
UlAverageSinrDb = 10 * log10 (среднее значение (UlSinr)) % конвертировать в дБ

Что касается количества хэндоверов, мы можем использовать простой сценарий оболочки для подсчета количества хендоверов.
появление строки "Handover" в файле журнала:

$ grep "Передача" no-op.txt | туалет -л

Таблица Результаты of сдавать кампании ниже показана полная статистика после того, как мы закончили
с постобработкой при каждом отдельном прогоне симуляции. Указанные значения являются средними
результатов, полученных от РнгРун из 1, 2, 3 и 4.

Результаты of сдавать кампании
┌ackindyacsideabults ───────────────┐
│Статистика │ Нет операций │ A2-A4-RSRQ │ Сильнейшая ячейка │
├ackим определителю ───────────────┤
│Средняя система DL │ 6 615 кбит/с │ 20 509 кбит/с │ 19 709 кбит/с │
│пропускная способность │ │ │ │
├ackим определителю ───────────────┤
│Средняя система UL │ 4 095 кбит/с │ 5 705 кбит/с │ 6 627 кбит/с │
│пропускная способность │ │ │ │
├ackим определителю ───────────────┤
│Средний DL SINR │ -0.10 дБ │ 5.19 дБ │ 5.24 дБ │
├ackим определителю ───────────────┤
│Средний UL SINR │ 9.54 дБ │ 81.57 дБ │ 79.65 дБ │
├ackим определителю ───────────────┤
│Количество хендоверов │ 0 │ 0.05694 │ 0.04771 │
│за единицу оборудования в секунду │ │ │ │
└ackим определителю ───────────────┘

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

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

лена-частота-повторное использование это простой пример с 3 eNB в треугольной компоновке. Есть 3 ячейки
крайние UE, которые расположены в центре этого треугольника, и 3 UE в центре соты (один рядом с
каждый eNB). Пользователь также может указать количество произвольно расположенных UE. Алгоритм FR
установлен в eNB, и каждый eNB имеет различный FrCellTypeId, что означает, что каждый eNB использует
разная конфигурация ФР. Пользователь может запустить лена-частота-повторное использование с 6 различными FR
алгоритмы: NoOp, Hard FR, Strict FR, Soft FR, Soft FFR и Enhanced FFR. Для запуска сценария
с алгоритмом распределенного FFR пользователь должен использовать лена-распределенный-ffr. Эти два примера
очень похожи, но они были разделены, потому что распределенный FFR требует использования EPC,
а другие алгоритмы - нет.

Бежать лена-частота-повторное использование с различными алгоритмами повторного использования частоты пользователю необходимо
укажите алгоритм FR, переопределив атрибут по умолчанию ns3::LteHelper::FfrAlgorithm.
Пример команды для запуска лена-частота-повторное использование с алгоритмом Soft FR представлен ниже:

$ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFrSoftAlgorithm"

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

Команда для генерации REM для RB 1 в канале данных из лена-частота-повторное использование сценарий с
Алгоритм Soft FR представлен ниже:

$ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFrSoftAlgorithm
--generateRem=true --remRbId=1"

Карта радиосреды для Soft FR представлена ​​на рисунке REM для RB 1 полученный от
лена-частота-повторное использование пример мягкая FR алгоритм включен.
[изображение] РЗМ для РБ 1, полученное из лена-частота-повторное использование пример с алгоритмом Soft FR
включено.UNINDENT

Команда для создания трассировки спектра из лена-частота-повторное использование сценарий с Soft FFR
алгоритм представлен ниже (позиция анализатора спектра должна быть настроена внутри
скрипт):

$ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFfrSoftAlgorithm
--generateSpectrumTrace=true"

Пример трассировки анализатора спектра представлен на рисунке. Спектр Анализатор прослеживать полученный
от лена-частота-повторное использование пример мягкая FFR алгоритм включен. Спектр Анализатор законопроект
расположенный eNB FrCellTypeId 2.. Как видно, разные поддиапазоны канала передачи данных
передаются с разным уровнем мощности (в соответствии с конфигурацией), а канал управления
передается с одинаковой мощностью по всей полосе пропускания системы.
[изображение] Трассировка анализатора спектра, полученная из лена-частота-повторное использование пример с Soft FFR
алгоритм включен. Анализатору спектра был нужен eNB с FrCellTypeId 2.. UNINDENT

лена-двойная полоса также может быть запущен с алгоритмами повторного использования частоты, установленными во всех макросах.
eNB. Пользователю необходимо указать алгоритм FR, переопределив атрибут по умолчанию.
ns3::LteHelper::FfrAlgorithm. Пример команды для запуска лена-двойная полоса с жестким FR
алгоритм представлен ниже:

$ ./waf --run="lena-dual-stripe
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::NoOpHandoverAlgorithm
--ns3::LteHelper::FfrAlgorithm=ns3::LteFrHardAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=no-op-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=no-op-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=no-op-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=no-op-UlSinrStats.txt
--RngRun=1" > no-op.txt

Пример команды для генерации REM для RB 1 в канале данных из лена-двойная полоса сценарий
с алгоритмом Hard FR представлен ниже:

$ ./waf --run="lena-dual-stripe
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=0 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::NoOpHandoverAlgorithm
--ns3::LteHelper::FfrAlgorithm=ns3::LteFrHardAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=no-op-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=no-op-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=no-op-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=no-op-UlSinrStats.txt
--RngRun=1 --generateRem=true --remRbId=1" > no-op.txt

Карты радиосреды для РБ 1, 10 и 20, сгенерированные из лена-двойная полоса сценарий с
Алгоритм Hard Frequency Reuse представлен на рисунках ниже. Эти РБ были выбраны
потому что каждый из них используется разными типами клеток FR.
[изображение] РЗМ для РБ 1, полученное из лена-двойная полоса моделирование с алгоритмом Hard FR
включено.UNINDENT
[изображение] РЗМ для РБ 10, полученное из лена-двойная полоса моделирование с алгоритмом Hard FR
включено.UNINDENT
[изображение] РЗМ для РБ 20, полученное из лена-двойная полоса моделирование с алгоритмом Hard FR
включено.UNINDENT

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

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

· сначала проверьте плоскость управления, в частности, установление соединения RRC
процедура, включив компоненты журнала LteUeRrc и LteEnbRrc

· затем проверьте передачу пакетов в плоскости данных, начиная с включения журнала
компоненты LteUeNetDevice и EpcSgwPgwApplication, затем EpcEnbApplication, затем
перемещение вниз по радиостеку LTE (PDCP, RLC, MAC и, наконец, PHY). Все это, пока вы
найти, где пакеты перестают обрабатываться/пересылаться.

Тестирование Документация
Обзор
Для тестирования и проверки модуля ns-3 LTE предоставляется несколько наборов тестов, которые
интегрирован с тестовой средой ns-3. Для их запуска необходимо настроить
построить симулятор таким образом:

$ ./waf configure --enable-tests --enable-modules=lte --enable-examples
$ ./test.py

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

Получить более подробный отчет в формате HTML можно так:

$ ./test.py -w результаты.html

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

Вы можете запустить каждый набор тестов отдельно, используя эту команду:

$ ./test.py -s имя-набора-тестов

Для получения дополнительной информации о test.py и фреймворк для тестирования ns-3, пожалуйста, обратитесь к ns-3
руководство.

Описание of тест люкс
Ед. Tests
SINR расчет in Downlink
Набор тестов lte-downlink-sinr проверяет, выполняется ли расчет SINR в нисходящем канале
правильно. SINR в нисходящем канале вычисляется для каждого RB, назначенного данным.
передачи путем деления мощности предполагаемого сигнала от рассматриваемого eNB на
сумма мощности шума плюс все передачи по одному и тому же RB, поступающие от других eNB
(сигналы помех):

В общем, разные сигналы могут быть активны в разные периоды времени. Мы определяем
кусок как временной интервал между любыми двумя событиями типа начало или конец
форма волны. Другими словами, блок определяет временной интервал, в течение которого набор
активные сигналы не меняются. Пусть i будет общим фрагментом, T_i его продолжительностью и
thrm{SINR_i} его SINR, рассчитанный по приведенному выше уравнению. Расчет среднего
SINR риme
Набор тестов проверяет правильность выполнения приведенных выше вычислений в симуляторе.
Тестовые векторы получаются в автономном режиме с помощью сценария Octave, который реализует описанное выше.
уравнение, и это воссоздает ряд случайных передаваемых сигналов и помех
сигналы, которые имитируют сценарий, в котором UE пытается декодировать сигнал от eNB, в то время как
сталкивается с помехами от других eNB. Тест считается пройденным, если вычисленные значения равны
тестовый вектор в пределах допуска 10^{-7}. Допуск предназначен для учета
ошибки аппроксимации типичны для арифметики с плавающей запятой.

SINR расчет in Хакеры:
Набор тестов lte-uplink-sinr проверяет, что вычисление SINR в восходящем канале выполнено
правильно. Этот набор тестов идентичен lte-downlink-sinr описано в предыдущем
раздел, с той разницей, что и сигнал, и помехи теперь относятся к
передачи UE, а прием выполняется eNB. Этот набор тестов
воссоздает ряд случайных передаваемых сигналов и сигналов помех, чтобы имитировать
сценарий, в котором eNB пытается одновременно декодировать сигнал от нескольких UE (т.
в соте eNB), сталкиваясь с помехами от других UE (тех, которые принадлежат
к другим ячейкам).

Тестовые векторы получаются с помощью специального сценария Octave. Тест проходит, если
рассчитанные значения равны тестовому вектору в пределах допуска 10^{-7}, что, как и для
тест SINR нисходящего канала имеет дело с проблемами аппроксимации арифметических операций с плавающей запятой.

Э-УТРА Absolute Радио частота Канал Номер регистрации (EARFCN)
Набор тестов lte-earfcn проверяет, что несущая частота, используемая
Класс LteSpectrumValueHelper (который реализует модель спектра LTE) выполняется в
соответствие [TS36101], где абсолютный номер радиочастотного канала E-UTRA
(EARFCN). Тестовый вектор для этого набора тестов содержит набор значений EARFCN.
и соответствующая несущая частота, рассчитанная вручную в соответствии со спецификацией
[TS36101]. Тест проходит успешно, если несущая частота, возвращаемая LteSpectrumValueHelper,
так же, как известное значение для каждого элемента в тестовом векторе.

Система Tests
Посвященный податель дезактивация Tests
Набор тестов lte-test-deactivate-bearer создает тестовый пример с одним EnodeB и тремя
УЭ. Каждое UE состоит из одного стандартного и одного выделенного канала EPS с одним и тем же каналом.
спецификации, но с другим ARP. Поток тестового примера выглядит следующим образом: Прикрепить UE -> Создать
По умолчанию + выделенный носитель -> деактивировать один из выделенных носителей

Тестовый пример дополнительно деактивирует выделенный однонаправленный канал с идентификатором однонаправленного канала 2 (LCID = BearerId + 2) из
Первое UE (UE_ID=1) Пользователь может запланировать деактивацию однонаправленного канала после определенной временной задержки, используя
Метод Simulator::Schedule().

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

|
Старт | конец | Идентификатор ячейки | ИМСИ | РНТИ | ЖКИ | TxBytes | RxBytes |

Тестовый пример выполняется в три эпохи. 1) В первой эпохе (0.04 с-1.04 с) все UE и
соответствующие носители присоединяются
и поток пакетов по выделенным однонаправленным каналам активирован.

2. Во второй эпохе (1.04 с-2.04 с) инициализируется деактивация канала-носителя, поэтому пользователь может видеть
относительно меньшее количество TxBytes на UE_ID=1 и LCID=4 по сравнению с другими каналами-носителями.

3. В третьей эпохе (2.04 с-3.04 с), поскольку деактивация канала-носителя UE_ID=1 и LCID=4
завершено, пользователь не увидит никаких журналов, связанных с LCID=4.

Тестовый пример проходит тогда и только тогда, когда 1) IMSI=1 и LCID=4 полностью удалены в третьей эпохе 2)
Не видно пакетов в TxBytes и RxBytes, соответствующих IMSI=1 и LCID=4 Если указано выше
критерий не соответствует тестовому случаю, который считается не пройденным

Адаптивный Модуляция и Кодирование Tests
Набор тестов lte-link-адаптация предоставляет системные тесты, воссоздающие сценарий с
один eNB и одно UE. Создаются разные тестовые случаи, соответствующие разным
Значения SNR, воспринимаемые UE. Цель теста состоит в том, чтобы проверить, что в каждом тестовом случае
выбранная MCS соответствует некоторым известным эталонным значениям. Эти эталонные значения получены
путем повторной реализации в Octave (см. источник/lte/тест/ссылка/lte_amc.m) модель, описанная в
Раздел sec-lte-amc для расчета спектральной эффективности и определения
соответствующий индекс MCS, вручную просматривая таблицы в [R1-081483]. Результирующий
тестовый вектор представлен на рисунке Тест вектор для Адаптивный Модуляция и Кодирование.

MCS, который используется симулятором, измеряется путем получения выходных данных трассировки.
производится планировщиком через 4 мс (это необходимо для учета начальной задержки в
отчет CQI). SINR, который рассчитывается симулятором, также получается с использованием
LteChunkПроцессор интерфейс. Тест считается пройденным, если выполняются оба следующих условия.
доволен:

1. SINR, рассчитанный симулятором, соответствует SNR тестового вектора в пределах
абсолютный допуск 10^{-7};

2. индекс MCS, используемый симулятором, точно соответствует индексу в тесте
вектор.
[изображение] Тестовый вектор для адаптивной модуляции и кодирования. UNINDENT

Межклеточный Вмешательство Tests
Набор тестов lte-помеха предоставляет системные тесты, воссоздающие межсотовую связь
сценарий помех с двумя eNB, к каждому из которых подключено одно UE и используется
Адаптивная модуляция и кодирование как в нисходящей, так и в восходящей линии связи. Топология
сценарий изображен на рисунке Топология для межклеточный вмешательство тест. d_1
Параметр представляет собой расстояние от каждого UE до eNB, к которому оно подключено, тогда как d_2
представляет собой расстояние до источника помех. Заметим, что топология сценария такова
что расстояние до источника помех одинаково для восходящей и нисходящей линий связи; все-таки настоящее
воспринимаемая мощность помех будет разной из-за разных потерь при распространении
в восходящем и нисходящем диапазонах. Различные тестовые примеры получаются путем изменения d_1 и
параметры d_2.
[изображение] Топология для теста на межсотовые помехи. UNINDENT

Тестовые векторы получаются с использованием специального октавного сценария (доступного в
src/lte/test/reference/lte_link_budget_interference.m), что делает бюджет ссылки
расчеты (включая помехи), соответствующие топологии каждого тестового примера,
и выводит результирующие SINR и спектральную эффективность. Затем последний используется для
определить (используя ту же процедуру, принятую для Адаптивный Модуляция и Кодирование Tests. Мы
обратите внимание, что тестовый вектор содержит отдельные значения для восходящей и нисходящей линий связи.

UE измерения Tests
Набор тестов lte-ue-измерения предоставляет системные тесты, воссоздающие межсотовую связь
сценарий вмешательства идентичен сценарию, определенному для lte-помеха тестирование.
Однако в этом тесте тестируемые количества представлены RSRP и RSRQ.
измерения, выполняемые UE в двух разных точках стека: источнике, который
является физическим уровнем UE, а пунктом назначения является RRC eNB.

Тестовые векторы получаются с использованием специального октавного сценария (доступного в
src/lte/test/reference/lte-ue-measurements.m), который выполняет расчет бюджета ссылки
(включая помехи), соответствующие топологии каждого теста, и выводит
результирующие RSRP и RSRQ. Полученные значения затем используются для проверки правильности
измерения UE на физическом уровне. После этого их необходимо преобразовать в соответствии с 3GPP.
форматирование с целью проверки их правильности на уровне RRC eNB.

UE измерение конфигурация тестов
Помимо ранее упомянутого набора тестов, есть еще 3 набора тестов для тестирования UE.
измерения: lte-ue-измерения-кусочно-1, lte-ue-измерения-кусочно-2 и
lte-ue-измерения-передача. Эти наборы тестов больше ориентированы на триггер отчетности.
процедура, т.е. корректность реализации запуска по событию
Критерии проверяются здесь.

Более конкретно, тесты проверяют синхронизация и содержание каждого отчета об измерениях
полученный eNodeB. Каждый тестовый пример представляет собой автономную симуляцию LTE, и тестовый пример будет
пройти, если отчет(ы) об измерении появляется только в предписанное время и показывает правильный
уровень RSRP (RSRQ на данный момент не проверен).

Кусочная конфигурация
Кусочная конфигурация предназначена для проверки конкретной конфигурации измерений UE.
Сценарий моделирования настроит соответствующую конфигурацию измерений для UE, которая
будет активен на протяжении всей симуляции.

Поскольку эталонные значения рассчитываются вручную, делается несколько допущений.
упростить моделирование. Во-первых, на канал влияет только модель потерь на пути (в данном случае
случае используется модель Фрииса). Во-вторых, используется идеальный протокол RRC, а уровень 3
фильтрация отключена. Наконец, UE перемещается по предопределенной схеме движения между 4
отчетливые пятна, как показано на рисунке UE движение прослеживать по всему моделирование in
кусочно конфигурация ниже. Следовательно, колебание измеренного RSRP может быть
определяется легче.
[изображение] Трассировка движения UE на протяжении всего моделирования в кусочной конфигурации. UNINDENT

Мотивация за "телепорт" между предопределенными точками состоит в том, чтобы ввести
резкое изменение уровня RSRP, что будет гарантировать срабатывание входа или выхода
состояние тестируемого события. Выполняя радикальные изменения, тест можно запустить в течение
меньшее количество времени.

Figure Измеренный РСРП прослеживать of an пример События A1 тест , признали in кусочно конфигурация
ниже показан измеренный RSRP после фильтрации уровня 1 уровнем PHY во время
моделирование с кусочной конфигурацией. Поскольку фильтрация уровня 3 отключена, эти
являются точными значениями, используемыми экземпляром RRC UE для оценки триггера создания отчетов.
процедура. Обратите внимание, что значения обновляются каждые 200 мс, что является значением по умолчанию.
период фильтрации отчета об измерениях уровня PHY. На рисунке также показано время, когда
входные и выходные условия примера события A1 (обслуживающая ячейка становится
лучше, чем порог) происходят во время моделирования.
[изображение] Измеренная трассировка RSRP примера тестового случая Event A1 по частям
конфигурация.UNINDENT

Каждый критерий отчетности тестируется несколько раз с различным порогом/смещением.
параметры. В некоторых тестовых сценариях также учитываются гистерезис и время срабатывания.
Figure Измеренный РСРП прослеживать of an пример События A1 гистерезис тест , признали in кусочно
конфигурация изображает эффект гистерезиса в другом примере теста события A1.
[изображение] Измеренная трассировка RSRP примера события A1 с тестовым случаем гистерезиса в
кусочная конфигурация.UNINDENT

Кусочная конфигурация используется в двух тестовых наборах измерений UE. Первый из них
lte-ue-измерения-кусочно-1, далее Кусочный тест №1, моделирующий 1 UE и
1 eNodeB. Другой lte-ue-измерения-кусочно-2, который имеет 1 UE и 2 eNodeB
в симуляции.

Кусочный тест №1 предназначен для проверки основанных на событиях критериев, которые не зависят
о существовании соседней ячейки. Эти критерии включают события A1 и A2.
другие события также кратко проверяются, чтобы убедиться, что они все еще работают правильно
(пусть и не сообщая ничего) при отсутствии какой-либо соседней ячейки. Стол UE
размеры тест Сценарии через кусочно конфигурация #1 ниже перечислены сценарии
проверено в кусочном тесте №1.

UE размеры тест Сценарии через кусочно конфигурация #1
┌ackindyacside ──┬─────────────────┐
│№ теста │ Отчетность │ Порог/смещение │ Гистерезис │ Время срабатывания │
│ │ Критерии │ │ │ │
├ackindyacside ──┼─────────────────┤
│1 │ Событие A1 │ Низкий │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│2 │ Событие A1 │ Норма │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│3 │ Событие A1 │ Нормальное │ Нет │ Короткое │
├ackindyacside ──┼─────────────────┤
│4 │ Событие A1 │ Нормальное │ Нет │ Длительное │
├ackindyacside ──┼─────────────────┤
│5 │ Событие A1 │ Нормальное │ Нет │ Супер │
├ackindyacside ──┼─────────────────┤
│6 │ Событие A1 │ Норма │ Да │ Нет │
├ackindyacside ──┼─────────────────┤
│7 │ Событие A1 │ Высокая │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│8 │ Событие A2 │ Низкий │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│9 │ Событие A2 │ Норма │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│10 │ Событие A2 │ Нормальное │ Нет │ Короткое │
├ackindyacside ──┼─────────────────┤
│11 │ Событие A2 │ Нормальное │ Нет │ Длительное │
├ackindyacside ──┼─────────────────┤
│12 │ Событие A2 │ Нормальное │ Нет │ Супер │
├ackindyacside ──┼─────────────────┤
│13 │ Событие A2 │ Норма │ Да │ Нет │
├ackindyacside ──┼─────────────────┤
│14 │ Событие A2 │ Высокая │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│15 │ Событие A3 │ Ноль │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│16 │ Событие A4 │ Норма │ Нет │ Нет │
└ackindyacside ──┴─────────────────┘

│17 │ Событие A5 │ Нормально-Нормально │ Нет │ Нет │
└ackindyacside ──┴─────────────────┘

Другие события, такие как события A3, A4 и A5, зависят от измерений соседней соты, поэтому
они более тщательно проверяются в кусочном тесте № 2. Моделирование помещает узлы на
прямой линии и дать указание UE "Прыжок" аналогично кусочному тесту №1.
Хэндовер в симуляции отключен, поэтому роль обслуживающей и соседней соты берут на себя.
не переключаться во время моделирования. Стол UE размеры тест Сценарии через кусочно
конфигурация #2 ниже перечислены сценарии, протестированные в кусочном тесте № 2.

UE размеры тест Сценарии через кусочно конфигурация #2
┌ackindyacside ──┬─────────────────┐
│№ теста │ Отчетность │ Порог/смещение │ Гистерезис │ Время срабатывания │
│ │ Критерии │ │ │ │
├ackindyacside ──┼─────────────────┤
│1 │ Событие A1 │ Низкий │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│2 │ Событие A1 │ Норма │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│3 │ Событие A1 │ Норма │ Да │ Нет │
├ackindyacside ──┼─────────────────┤
│4 │ Событие A1 │ Высокая │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│5 │ Событие A2 │ Низкий │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│6 │ Событие A2 │ Норма │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│7 │ Событие A2 │ Норма │ Да │ Нет │
├ackindyacside ──┼─────────────────┤
│8 │ Событие A2 │ Высокая │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│9 │ Событие A3 │ Положительный │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│10 │ Событие A3 │ Ноль │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│11 │ Событие A3 │ Ноль │ Нет │ Короткий │
├ackindyacside ──┼─────────────────┤
│12 │ Событие A3 │ Ноль │ Нет │ Супер │
├ackindyacside ──┼─────────────────┤
│13 │ Событие A3 │ Ноль │ Да │ Нет │
├ackindyacside ──┼─────────────────┤
│14 │ Событие A3 │ Отрицательно │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│15 │ Событие A4 │ Низкий │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│16 │ Событие A4 │ Норма │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│17 │ Событие A4 │ Нормальное │ Нет │ Короткое │
├ackindyacside ──┼─────────────────┤
│18 │ Событие A4 │ Нормальное │ Нет │ Супер │
├ackindyacside ──┼─────────────────┤
│19 │ Событие A4 │ Норма │ Да │ Нет │
├ackindyacside ──┼─────────────────┤
│20 │ Событие A4 │ Высокая │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│21 │ Событие A5 │ Низкий-низкий │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│22 │ Событие A5 │ Низкий-нормальный │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│23 │ Событие A5 │ Низкий-высокий │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│24 │ Событие A5 │ Нормальный-Низкий │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│25 │ Событие A5 │ Нормально-Нормально │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│26 │ Событие A5 │ Нормально-Нормально │ Нет │ Короткий │
├ackindyacside ──┼─────────────────┤
│27 │ Событие A5 │ Нормально-Нормально │ Нет │ Супер │
├ackindyacside ──┼─────────────────┤
│28 │ Событие A5 │ Нормально-Нормально │ Да │ Нет │
├ackindyacside ──┼─────────────────┤
│29 │ Событие A5 │ Нормально-высокий │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│30 │ Событие A5 │ Высокий-низкий │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│31 │ Событие A5 │ Высокий-Нормальный │ Нет │ Нет │
├ackindyacside ──┼─────────────────┤
│32 │ Событие A5 │ Высокий-Высокий │ Нет │ Нет │
└ackindyacside ──┴─────────────────┘

Одно замечание о тестах с временем до срабатывания, они тестируются с использованием 3 разных значений
время срабатывания: короткие (короче интервала отчета), длинной (короче фильтр
период измерения 200 мс), и супер (более 200 мс). Первые два обеспечивают
оценка времени до срабатывания всегда использовать последние отчеты об измерениях, полученные от PHY
слой. В то время как последний отвечает за проверку времени до срабатывания отмены, для
пример, когда отчет об измерении с PHY показывает, что условие входа/выхода не
дольше true до срабатывания первого триггера.

Сдавать конфигурация
Цель конфигурации передачи обслуживания состоит в том, чтобы проверить, соответствует ли измерение UE
конфигурация обновляется должным образом после успешной передачи обслуживания. Для этого
Для этой цели моделирование создаст 2 eNodeB с разными измерениями UE.
конфигурации, и UE выполнит передачу обслуживания из одной соты в другую. УП будет
расположен на прямой линии между 2 eNodeB, и передача обслуживания будет инициирована
вручную. Продолжительность каждой симуляции составляет 2 секунды (кроме последнего теста).
хендовер запускается ровно на полпути моделирования.

Команда lte-ue-измерения-передача набор тестов охватывает различные типы конфигурации
различия. Первый – это разница в интервале между отчетами, например, первый eNodeB
настроен с интервалом отчета 480 мс, а второй eNodeB настроен с 240 мс
интервал отчета. Следовательно, когда UE выполнило передачу обслуживания во вторую соту, новый
интервал отчета должен вступить в силу. Как и в кусочной конфигурации, время и
содержание каждого отчета об измерении, полученного eNodeB, будет проверено.

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

UE размеры тест Сценарии через сдавать конфигурация
───────────────────────────────────────────────────── ───────────────────────
Тест # Испытуемый Испытуемый Начальный пост-передача
Конфигурация Конфигурация
───────────────────────────────────────────────────── ───────────────────────
1 Интервал отчета 480 мс 240 мс
───────────────────────────────────────────────────── ───────────────────────
2 Интервал отчета 120 мс 640 мс
───────────────────────────────────────────────────── ───────────────────────
3 Событие Событие A1 Событие A2
───────────────────────────────────────────────────── ───────────────────────
4 Событие Событие A2 Событие A1
───────────────────────────────────────────────────── ───────────────────────
5 Событие Событие A3 Событие A4
───────────────────────────────────────────────────── ───────────────────────
6 Событие Событие A4 Событие A3
───────────────────────────────────────────────────── ───────────────────────
7 Событие Событие A2 Событие A3
───────────────────────────────────────────────────── ───────────────────────
8 Событие Событие A3 Событие A2
───────────────────────────────────────────────────── ───────────────────────
9 Событие Событие A4 Событие A5
───────────────────────────────────────────────────── ───────────────────────
10 Событие Событие A5 Событие A4
───────────────────────────────────────────────────── ───────────────────────
11 Порог/смещение Диапазон RSRP 52 Диапазон RSRP 56
(Событие А1) (Событие А1)
───────────────────────────────────────────────────── ───────────────────────
12 Порог/смещение Диапазон RSRP 52 Диапазон RSRP 56
(Событие А2) (Событие А2)
───────────────────────────────────────────────────── ───────────────────────
13 Порог/смещение Смещение A3 -30 Смещение A3 +30
(Событие А3) (Событие А3)
───────────────────────────────────────────────────── ───────────────────────
14 Порог/смещение Диапазон RSRP 52 Диапазон RSRP 56
(Событие А4) (Событие А4)
───────────────────────────────────────────────────── ───────────────────────
15 Порог/смещение Диапазон RSRP 52–52 Диапазон RSRP 56–56
(Событие А5) (Событие А5)
───────────────────────────────────────────────────── ───────────────────────
16 Время срабатывания 1024 мс 100 мс
───────────────────────────────────────────────────── ───────────────────────
17 Время срабатывания 1024 мс 640 мс
┌ackindyacside ─────────────────────┐
│ │ │ │ │
Двоичный файл (стандартный ввод) соответствует

Используйте ns-3-model-library онлайн с помощью сервисов onworks.net