Глава 4. Модуль спутниковой связи Satellite

В данной главе будет дано краткое описание классов модуля Satellite (их углубленное описание будет представлено в главе 6) и рассмотрена работа с его моделью спутниковой связи.

Полное название модуля: Satellite Network Simulator 3 (SNS-3). Исходный код модуля можно получить на Github: https://github.com/sns3/sns3-satellite

Satellite - это расширение симулятора NS-3, предназначенное для работы со спутниковыми сетями. Первоначально Satellite был разработан компанией Magister Solutions по контракту с ЕКА (Европейское Космическое Агенство). В настоящий момент работа над модулем ведется во Французском космическом агентстве (CNES). Онлайн документацию к модулю можно найти по ссылке: https://www.sns3.org/index.html.

4.1 Обзор модуля

Модуль реализует широкий спектр механизмов DVB-S2/RCS2 (некоторые примеры моделируют работу в стандарте LoRa):

• Адаптивное кодирование и модуляция ( ACM);

• Планирование прямого и обратного каналов;

• Множественный доступ с предоставлением канала по требованию (DAMA):

  • Постоянное выделение ресурса ( CRA);

  • Динамическая емкость на основе скорости (RBDC);

  • Динамическая емкость на основе объема (VBDC);

  • Выделение свободной емкости (FCA).

• Произвольный доступ (RA): - Слоты ALOHA и CRDSA (многослотовый ALOHA с разрешением коллизий); - Инкапсуляция потоков общего назначения (GSE).

• Инкапсуляция обратного канала (RLE);

• Автоматический запрос на повторение (ARQ) через двунаправленный уровень конвергенции LLC;

• Модели диаграмм направленности многолучевых спутниковых антенн;

• Вычисление отношения сигнал/помеха+шум (SNIR) для каждого пакета;

• Отслеживание внутрилучевых и межлучевых помех для каждого пакета;

• Метеорологические данные, канал LMS (спутниковая связь с наземными подвижными объектами);

• Модели ошибок на основе кривых BER (коэффициента битовых ошибок).

4.2 Дизайн

В качестве эталонной схемы эксперимента рассматривается один многолучевой спутник на геостационарной орбите на высоте около 35786 км ( но можно моделировать и сложные созвездия LEO/MEO). Зона обслуживания системы — Европа, с использованием одного спутника, расположенного на 33 градусе восточной долготы и использующего частоты Ka-диапазона (от 26,5 до 40,0 ГГц) на фидерных линиях и линиях связи с пользователями. Покрытие пользовательских линий связи обеспечивается 72 точечными лучами (в программном коде количество лучей ограничено числом 1000), а обслуживание пользовательских лучей осуществляется через 5 шлюзов (в программном коде количество не ограничено). Это показано на диаграмме усиления антенн, рисунок 4.1.

В системе для фидерной линии выделяется 2 ГГц полоса: от 27,5 до 29,5 ГГц для восходящей линии связи и от 17,7 до 19,7 ГГц для нисходящей линии связи, как показано в частотном плане спутника на рисунке 4.2.

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

Для пользовательской линии выделяется 500 МГц: полоса от 29,5 до 30 ГГц для восходящей линии связи и от 19,7 до 20,2 ГГц для нисходящей. Эта полоса 500 МГц разделена на четыре поддиапазона по 125 МГц (т.е. четырехцветное повторное использование). Схема повторного использования частот для пользовательской линии представлена на карте доминирования (dominance map) 72-лучевой эталонной системы с идентификаторами частот для пользователей, рисунок 4.3. Каждому точечному лучу выделяется полоса 125 МГц на восходящей линии и другая полоса 125 МГц на нисходящей линии пользовательской связи. Каждая шлюзовая станция может поддерживать агрегированный трафик для 16 лучей (2 ГГц / 125 МГц = 16). Таким образом, каждый шлюз сопоставляется с 16 лучами. Поскольку система включает всего 72 точечных луча, для их обслуживания необходимы пять шлюзов.

Модуль Satellite, для обеспечения гибкости его применения, спроектирован по модульному принципу. Это позволяет его о использовать с минимальными изменениями исходного кода для моделирования различных интерактивных прозрачных геостационарных спутниковых сетей. В качестве стандартов связи на прямой и обратной линиях приняты спецификации ETSI DVB-S2 и DVB-RCS2. Почти каждый аспект функциональности спутникового модуля легко настраивается с помощью многочисленных атрибутов (класс AttributeValue раздел 5.1). Атрибуты можно задавать через входные XML-файлы, жестко прописывать в сценариях или передавать в качестве аргументов командной строки в стиле NS-3. Для облегчения настройки существует вспомогательный класс (SimulationHelper подраздел 6.5.1), который позволяет настраивать атрибуты группами, используя простые вызовы функций в сценариях моделирования.

4.2.1 Конфигурация кадра

Обратная линия связи использует множественный доступ с частотным и временным разделением (MF-TDMA), который состоит из последовательностей суперкадров, кадров, временных слотов и единиц времени полосы пропускания ( BTU) [TS 101 545-1 - V1.1.1 - Digital Video Broadcasting (DVB); Second Generation DVB Interactive Satellite System (DVB-RCS2); Part 1: Overview and System Level Specification.]. Используемые структуры кадров динамически конфигурируются центром управления сетью (NCC) с помощью таблицы композиции суперкадров (SCT), таблицы композиции кадров версии 2 (FCT2 ) и широковещательной таблицы композиции (BCT). Модуль не моделирует явно SCT, FCT и BCT, но конфигурации кадров могут изменяться путем параметризации. Пример структур кадров представлен в разделе 5.2.3 руководства DVB-RCS2 [ Digital Video Broadcasting (DVB); Second Generation Framing Structure, Channel Coding and Modulation Systems for Broadcasting, Interactive Services, News Gathering and Other Broadband Satellite Applications; Part 1: DVB-S2]. Однако NCC моделирует план временных интервалов терминала версии 2 (TBTPv2) и, таким образом, способен динамически конфигурировать временные слоты для каждого суперкадра (например, время начала, длительность, формы сигналов). Прямая линия связи использует структуру временного мультиплексирования (TDM) стандарта DVB-S2, которая описана в разделе 5 документа (ETSI-EN-302-307-1-V1-4-1-2014-11-.pdf). Полоса пропускания фидерной линии прямой связи шириной 2 ГГц разделена на 16 несущих по 125 МГц, где каждая несущая статически сопоставляется с цветом пользовательской частоты 125 МГц для определенного луча. Обратите внимание, что поддерживается только одна несущая на луч.

4.3 Архитектура

Модуль построен на основе универсальной модели NetDevice (sec:ClassNetDevice) из NS-3, Satellite предлагает упомянутую выше реалистичную модель, соответствующую спутнику связи с высокой пропускной способностью (HTS), с 72 лучами и 5 шлюзами (что впрочем не мешает сконфигурировать модель спутника с другими параметрами). Архитектура типичной моделируемой системы показана на рисунке 4.4.

Она включает в себя модели:

• пользовательского терминала (UT);

• спутника (SAT);

• шлюза (GW);

• центра управления сетью (NCC), на рисунке не показан;

• наземных узлов (конечных пользователей);

• модели взаимодействия перечисленных устройств.

Как правило, для спутниковых узлов требуется класс спутникового сетевого устройства (SatNetDevice раздел 6.1), который является потомком класса NetDevice (раздел 5.7). SatNetDevice реализует классы управления:

• логическим каналом (LLC);

• доступом к среде (MAC);

• физическим уровнем (PHY).

Классы специфичные для каждого узла. Кроме того, для поддержки расчетов мощности принимаемого сигнала, используется класс спутникового канала (SatChannel раздел 6.14). Используемая на наземном участке связи технология доступа (UT или GW) может быть любой, поддерживаемой NS-3, например, «точка-точка», CSMA, Wi-Fi. Текущие вспомогательные классы (helpers sec:Helper_classes) предполагают использование CSMA. Модуль NCC моделируется как общий модуль для всех узлов GW. Модуль Satellite в дополнение к стандартной декартовой системе координат реализует работу как в сферической, так и геодезической системах координат (WGS84 и GRS84) (широта, долгота, высота). Новые системы координат необходимы для узлов спутникового домена (UT, спутник и GW).

4.3.1 Пользовательский терминал (UT)

В пользовательском терминале (UT) реализована логика пакетной передачи на основе стандарта DVB-RCS2 (для обратного канала) и логика приема кадров BBFrame на основе стандарта DVB-S2 (для прямого канала). Входящие IPпакеты буферизируются на уровне LLC, который реализует инкапсуляцию обратного канала (RLE), а также функции фрагментации и компоновки пакетов для таймслотов обратного канала. Класс «Менеджер запросов» (Request Manager) отслеживает состояние очередей и запрашивает ресурсы у центра управления сетью (NCC), отправляя запросы емкости (CR) с указанием категорией емкости (CC), такой как динамическая емкость на основе скорости (RBDC) и динамическая емкость на основе объема (VBDC). MAC-уровень отвечает за обработку полученных таблиц TBTP (план временных интервалов терминала) и планирование таймслотов, а физический уровень (PHY) - за непосредственную передачу и прием пакетов в канале связи. Структура UT представлена на рисунке 4.5.

4.3.2 Геостационарный спутник

В настоящее время спутниковый модуль поддерживает прозрачную (ретрансляционную) полезную нагрузку, при которой пользовательские линии и линии «вверх-вниз» (фидерные линии) напрямую сопоставляются друг с другом. Спутник только усиливает сигнал, не выполняя никакой обработки пакетов. Обратите внимание, что геостационарный (GEO) спутник также рассчитывает SINR (отношение сигнал/помеха+шум), поскольку была принята двухфазная методика вычисления SINR. Величина SINR рассчитывается отдельно для пользовательских и фидерных линий и объединяется на конечном приемнике с помощью составного уравнения SINR. Структура спутника представлена на рисунке 4.6.

4.3.3 Шлюз (GW)

В шлюзе (Gateway) реализована логика передачи на основе DVB-S2 и логика приема на основе DVB-RCS2. Архитектура SatNetDevice шлюза в целом довольно похожа на архитектуру описанного выше пользовательского терминала (UT). Однако основное отличие заключается в том, что у GW имеется столько SatNetDevice, сколько пятен (spot-beams) он обслуживает; таким образом, один SatNetDevice обслуживает все пользовательские терминалы в пределах одного пятна. На уровне LLC шлюза для каждого подключенного пользовательского терминала существует один объект инкапсуляции Generic Stream Encapsulation (GSE). Передатчик DVB-S2 постоянно передает базовые кадры ( BBFrame), причем каждый такой кадр содержит пакеты вышележащих уровней только с одним значением MODCOD. Длина кадра BBFrame может составлять 16200 или 64800 кодированных бит, поэтому время передачи одного кадра зависит от MODCOD. Если у шлюза нет данных для передачи, он генерирует фиктивные (dummy) кадры. Структура шлюза представлена на рисунке 4.7.

4.3.4 Центр управления сетью (NCC)

Центр управления сетью (Network Control Centre, NCC) отвечает за распределение ресурсов обратного канала:

• управление доступом (admission control);

• диспетчеризацию пакетов (packet scheduling);

• адаптивная модуляция и кодирование (ACM).

В модуле Satellite реализован один, глобальный NCC, который имеет полностью отдельный планировщик (SatBeamScheduler) для каждого пятна (spot-beam). Чтобы избежать реализации протокола связи между шлюзами (GW) и NCC, центр управления сетью подключен к каждому GW и SatNetDevice с помощью обратных вызовов (callbacks) NS-3. Это позволяет, с одной стороны, обеспечить идеальный канал связи между NCC и GW, а с другой стороны, в дальнейшем его легко можно заменить на реальный протокол.

4.3.5 Канал

Реализация спутникового канала в модуле (SatChannel раздел 6.14) привязана к определенному частотному цвету (полосе частот). Основное назначение канала - обеспечить возможность передачи пакетов в пределах одной полосы частот всем приемникам, использующим ту же полосу. Другими словами, все совмещенные по частоте лучи (co-channel beams) используют один и тот же канал, а лучи в разных частотных диапазонах полностью разделены по разным экземплярам каналов. В пользовательской линии (user link) существуют всего четыре экземпляра канала (SatChannel) на каждое направление, каждый из которых представляет одну полосу пропускания шириной 125 МГц. В используемой эталонной системе в общей сложности 72 / 4 = 18 пятен (spot-beams) используют один и тот же канал пользовательской линии. Таким образом, пользовательские терминалы (UT) в пределах этих 18 пятен, разделяющих один канал, потенциально могут создавать помехи друг другу. В фидерной линии (feeder link) существуют всего 16 экземпляров канала на каждое направление (2 ГГц / 0,125 ГГц), каждый из которых представляет полосу пропускания 125 МГц. Все шлюзы (GW) используют один и тот же диапазон частот, поэтому в одном экземпляре канала могут работать максимум 5 шлюзов одновременно. На рисунке 4.8 проиллюстрировано моделирование канала для подмножества из 16 лучей, входящих в полную сцену с 72 лучами.

4.3.6 Произвольный доступ

Поддерживаются три режима произвольного доступа:

• слотированный ALOHA [TS 101 545-1 - V1.1.1 - Digital Video Broadcasting (DVB); Second Generation DVB Interactive Satellite System (DVB-RCS2); Part 1: Overview and System Level Specication.];

• слотированный ALOHA с подавлением коллизий на основе множественных копий (CRDSA)[ Contention Resolution Diversity Slotted ALOHA (CRDSA): An Enhanced Random Access Schemefor Satellite Access Packet Networks];

• многокопийное декодирование с корреляционной локализацией (MARSALA) [k.zidane_thesis.pdf ].

Слотированный ALOHA, из-за ограничений на размер полезной нагрузки, используется только для служебных сообщений. Реализованы запросы ресурсов (CR) и квитанции ARQ ACK, которые могут передаваться через слотированный ALOHA.

Алгоритмы CRDSA основаны на [TS1015451] и [ContentionResolutionDiversity]. Стандарт DVB-RCS2 определяет шесть сценариев использования CRDSA:

• холодный старт в режиме произвольного доступа;

• дозаказ ресурсов в режиме RA-DAMA;

• резервирование RA-DAMA;

• IP-очередь для RA;

• запросы ресурсов через RA и RA для SCADA;

• помимо «запросов ресурсов через RA», спутниковый модуль поддерживает сценарий «холодного старта в RA», что повышает пропускную способность и снижает задержки пакетов в тех случаях, когда у терминала (UT) нет доступных ресурсов с гарантированной скоростью (DA).

Алгоритм MARSALA, описанный в [https://www.tesa.prd.fr/documents/26/k.zidane_thesis.pdf], предназначен для улучшения характеристик CRDSA в тех случаях, когда цикл последовательного подавления помех (SIC) не дает результата.

4.3.7 Планировщик пакетов обратной линии

Функциональность планировщика пакетов обратной линии связи реализована в едином, глобальном центре управления сетью (NCC). Он содержит независимые планировщики для каждого точечного луча, которые никак не взаимодействуют друг с другом. Планировщик обратной линии связи может работать в одном из трех режимов конфигурации временных слотов: 0–2.

Conf-0 (Конфигурация 0): Планировщик настраивается с предопределенной структурой временных слотов со статической формой сигнала (т.е. фиксированной длительностью пакета и MODCOD).

Conf-1 (Конфигурация 1): Планировщик настраивается с предопределенной структурой временных слотов со статической длительностью пакета, но MODCOD может изменяться между временными слотами/пользовательскими терминалами (UT).

Conf-2 (Конфигурация 2): Планировщик генерирует временные слоты динамически («на лету») в зависимости от запросов UT, условий канала и загрузки. Каждый временной слот может использовать любую волновую форму сигнала.

Спутниковый модуль поддерживает волновые формы с 3 по 22, то есть MODCOD от QPSK 1/3 до 16QAM 5/6 с двумя различными длительностями пакетов (536 и 1616 символов) [ Guidelines for the Implementation and Use of EN 301 545-2 (DVB-RCS2 Lower Layer) ]. Остальные волновые формы не поддерживаются из-за отсутствия результатов моделирования линии связи. Шлюз (GW) измеряет отношение несущая/шум плюс помехи ( ) обратной линии для каждого принятого временного слота, добавляет погрешность измерения и пересылает отчет в NCC. NCC выбирает для каждого UT тот MODCOD, который обеспечивает наилучшую спектральную эффективность, одновременно гарантируя согласованный уровень ошибок. Процесс планирования обратной линии связи для одного отдельного планировщика луча состоит из шести последовательных этапов [ Radio Resource Management in DVB-RCS2 Satellite Systems]:

1. SatDamaEntry/CR update (обновление запросов емкости): Обработка полученных запросов емкости (CR) в пределах предыдущего суперкадра.

2. Preliminary resource allocation (предварительное распределение ресурсов): Предварительное выделение набора «мягких» символов для каждого UT на основе настроенной постоянной скорости доступа (CRA), типа динамического запроса (RBDC, VBDC) и его значения, условий , конфигурации кадров и загрузки.

3. Time slot generation (генерация временных слотов): Создание временных слотов для каждого кадра на основе предварительно выделенных «мягких» символов для каждого UT и индекса класса RC. Динамическое заполнение плана временных интервалов терминала (TBTP).

4. SatDamaEntry update (обновление записи DAMA): Обновление выделенных байтов VBDC для каждого контекста UT.

5. TBTP signaling (сигнализация TBTP): Отправка сообщения TBTP в соответствующий стек протоколов шлюзовой станции (GW), который управляет ресурсами для данного конкретного точечного луча.

6. Schedule next scheduling time (планирование следующего цикла): Назначение времени следующего планирования для следующего суперкадра (SF).

1.3.8 Множественный доступ с назначением по запросу (DAMA)

Оценка множественного доступа с назначением по запросу (DAMA) реализована в диспетчере запросов (RM) [RadioResourceManagement]. Алгоритмы DAMA основаны на [cuestaInnovativeDAMAAlgorithm2013]. RM настраивается через конфигурацию сервисов нижнего уровня, при этом конфигурация DAMA может задаваться отдельно для каждого индекса RC. Класс SatRequestManager (sec:ClassSatRequestManager) модуля Satellite поддерживает следующие виды распределения ёмкости:

• CRA

• RBDC

• VBDC.

Диспетчер запросов периодически или по мере надобности оценивает необходимость отправки запроса на выделение ёмкости для определенного индекса RC. Он отслеживает очереди пакетов UT, анализируя интенсивность входящего трафика и полученные ресурсы DA от TBTP. CR моделируется как реальное сигнальное сообщение с вероятностью ошибки передачи.

4.3.9 Планировщик пользовательских терминалов

Планировщик пользовательских терминалов (UT scheduler) планирует возможности передачи (временные слоты) для верхнего уровня на основе сообщений TBTP, полученных от Центра управления сетью (NCC). Планировщик UT преимущественно следует индексам RC, указанным в TBTP, однако в случае отсутствия пакетов в определённом инкапсуляторе/очереди RLE для заданного индекса RC, планировщик вправе выбрать для обслуживания другой индекс RC.

4.3.10 Планировщик прямого канала

Планировщик прямого канала (FWD link scheduler раздел 6.9) периодически формирует набор BBкадров и заполняет их пакетами GSE из LLC в порядке приоритета. Для BB-кадров выделяется оптимальный режим MODCOD на основе отчетов C N 0 для конкретного UT. После раунда планирования планировщик пытается оптимизировать BBкадры путем понижения режима MODCOD по мере необходимости, чтобы минимизировать количество BB-кадров.

4.3.11 Автоматический запрос повтора (ARQ)

Механизм ARQ не входит в спецификации DVB-RCS2. Однако в исследовательских целях в модуле был реализован ARQ с выборочным повторением (Selective Repeat ARQ). ARQ работает на уровне LLC и оперирует пакетами GSE (для прямого канала) или RLE (для обратного канала).

4.3.12 Мобильность и хендовер

Для пользовательских терминалов (UT) реализовано две модели мобильности:

• статическая;

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

Для движущихся UT промежуточные позиции вычисляются по мере необходимости с помощью линейной интерполяции между двумя ближайшими позициями в файле. После достижения позиции, указанной в конце файла, UT остаётся неподвижным до конца моделирования. Существует модуль хендовера (передача обслуживания), который может быть подключён к любому UT. При наличии такого модуля, UT отслеживает мощность несущих сигналов в окружающей зоне. Когда мощность несущей, к которой он привязан, падает ниже заданного порога, модуль отправляет в NCC запрос на разрешение выполнения хендовера на другую указанную несущую/луч.

1.4 Установка модуля

Модуль Satellite устанавливается в директорию contrib путем клонирования соответствующего репозитория с Github и последующей сборки. На момент написания этого руководства, разработчиками рекомендовалось использовать модуль совместно с версией ns3 3.43. По этой причине создадим новую рабочую директорию с именем workspace_ns3.43:

$ mkdir workspace_ns3.43 

Переходим в директорию и выполняем клонирование проекта симулятора NS-3:

$ cd workspace_ns3.43
$ git clone https://gitlab.com/nsnam/ns-3-dev.git ns-3.43

Аргумент «ns-3.43» указывает имя папки, которая будет создана у вас локально. Если не указать, папка назовется так же, как репозиторий (ns-3-dev). Переходим в папку contrib симулятора:

$ cd ~/workspace_ns3.43/ns-3.43/contrib 

Выполняем клонирование модуля sns3-satellite в эту папку. Существует два варианта действий, установить модуль в «первозданном» виде из репозитория разработчиков:

$ git clone https://github.com/sns3/sns3-satellite.git satellite

либо установить форк, изменения в котором связаны с моделированием HAP(High-Altitude Platform или высотная стратосферная платформа) (исправлен метод добавления тегов в пакет, добавлен функционал задания траектории HAP):

$ git clone https://github.com/chetverovod/sns3-satellite.git satellite

в ней появится новая директория с именем satellite. Далее клонируем используемые Satellite модули traffic и magister-stats:

$ git clone https://github.com/sns3/traffic.git traffic

$ git clone https://github.com/sns3/stats.git magister-stats

Теперь на нужно переключить скачанные репозитории на состояние соответствующее версии 3.43. Для этого переходим в директорию ns-3.43:

$  cd ~/workspace_ns3.43/ns-3.43 

и делаем checkout на тег соответствующий релизу ns-3.43:

$  git checkout ns-3.43 

Git в ответ выведет в консоль большое сообщение заканчивающееся строкой:

HEAD is now at 753817468 Update VERSION and documentation tags for ns-3.43 release

Выполняем аналогичные действия для репозиториев satellite, traffic, magister-stats:

$  cd ~/workspace_ns3.43/ns-3.43/contrib/satellite
$  git checkout 3.43 
$  cd ~/workspace_ns3.43/ns-3.43/contrib/traffic
$  git checkout 3.43
$  cd ~/workspace_ns3.43/ns-3.43/contrib/magister-stats
$  git checkout 3.43

Существуют два способа сборки модуля Satellite:

• автоматический с использованием bake;

• полуавтоматический с использованием CMake.

Авторы модуля рекомендуют выбрать метод с использованием CMake. Выполняем сборку симулятора:

$  cd ~/workspace_ns3.43/ns-3.43/
$ ./ns3 clean
$ ./ns3 configure --build-profile=optimized --enable-examples --enable-tests
$ ./ns3 build 

Сборка с ключом --build-profile=optimized соответствует релизной сборке. Без этого ключа по умолчанию будет выполняться сборка симулятора для режима debug, который содержит много проверок и работает медленно (в 10-20 раз). Сборка успешно завершится, но с предупреждением о том, что в одном из тестов делается попытка удалить несуществующий объект:

at /home/igor/workspace_ns3.43/ns-3.43/src/core/test/attribute-container-test-suite.cc:472:40:
/home/igor/workspace_ns3.43/ns-3.43/src/core/model/attribute-container.h:424:1: warning: ‘void operator delete(void*, std::size_t)’ called on unallocated object ‘<anonymous>’ [-Wfree-nonheap-object]
  424 | }
      | ^
/home/igor/workspace_ns3.43/ns-3.43/src/core/test/attribute-container-test-suite.cc: In member function ‘virtual void AttributeContainerSetGetTestCase::DoRun()’:
/home/igor/workspace_ns3.43/ns-3.43/src/core/test/attribute-container-test-suite.cc:472:87: note: declared here
  472 |     obj->SetAttribute("IntegerVector", AttributeContainerValue<IntegerValue, ';'>(ints));
      |                                                                                       ^

и сообщением о том, что все исполняемые файлы симулятора скомпилированы:

[2405/2405] Linking CXX executable /home/igor/worksp...ld/utils/ns3.43-print-introspected-doxygen-optimized
Finished executing the following commands:
/usr/bin/cmake --build /home/igor/workspace_ns3.43/ns-3.43/cmake-cache -j 3

Данный результат получен при сборке компилятором g++ версии:

g++ (Ubuntu 11.4.0-1ubuntu1~22.04.2) 11.4.0 

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

$  cd ~/workspace_ns3.43/ns-3.43/contrib/satellite
$  git submodule update --init --recursive

Обновление данных завершится сообщением:

Submodule path 'data': checked out 'da089030e20e7857a00d72c764aee40306dc0ee1' 

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

$  cd ~/workspace_ns3.43/ns-3.43
$ ./test.py --no-build

Тестирование должно закончиться сообщением:

865 of 865 tests passed (865 passed, 0 skipped, 0 failed, 0 crashed, 0 valgrind errors)

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

$ ./ns3 show targets | grep sat 

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

4.5 Документация к модулю

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

$ cd ~/workspace_ns3.43/ns-3.43/contrib/satellite/doc

В ней находится make-файл для сборки. В файле README.md даны инструкции. Чтобы собрать документацию в виде html -документа устанавливаем doxygen командой:

$ sudo apt-get  install doxygen

и запускаем сборку:

$ make doxygen

Она закончится сообщением:

Build finished. The doxygen doc is in build/html

Результатом работы будет появление html файлов в папке /home/igor/workspace_ns3.43/ns-3.43/contrib/satellite/doc/build/doxygen/html

Для просмотра документации открываем в браузере файл index.html.

В файле README.md даны инструкции для сборки документации еще в нескольких форматах.

На сегодня это всё. В следующей статье цикла мы выборочно познакомимся с классами симулятора NS-3 которые будут использоваться в повседневной работе при создании симуляций.

Работа выполнена в рамках Программы создания и развития центра НТИ на базе МФТИ, Физтех по направлению («сквозной» технологии) Национальной технологической инициативы «Перспективные технологии для космических систем и сервисов» при реализации комплексного научно-исследовательского и опытно-конструкторского проекта “Разработка комплексной среды моделирования и проектирования гибридных инфокоммуникационных сетей наземного, стратосферного и космического сегментов с использованием параметрического и структурного синтеза”.