NS-3 WimaxNetDeviceЭта статья описывает ns-3 WimaxNetDevice и связанные с ним модели. Добавляя объекты

WimaxNetDevice в узлы NS3 можно создавать модели сетей основанных на стандарте IEEE 802.16. Ниже будут перечислены основные детали модели ns-3 Wimax.

В целом наиболее важными особенностями модели NS3 является: Масштабируемость и реалистичный физический и канальный уровень модели Пакетный классификатор для подуровня конвергенции IP протокола Эффективная организация нисходящего и восходящего субкадра. Поддержка Multicast и Broadcast сервисов Поддержка трассировки пакетовИсходные коды Wimax модели находятся в директории src/wimax.

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

станции (SS) и базовой станции (BS). Они реализованы в виде двух подклассов базового класса ns3::NetDevice, класс SubscriberStationNetDevice и BaseStationNetDevice. Так же ns3 имеет физический класс WimaxPhy и канальный класс WimaxChannel который служит для хранения ссылок на все подключенные к нему устройства физического уровня. Главный класс физического уровня это класс SimpleOfdmWimaxChannel.

Другие важные аспект Wimax это процедура обработки запросов полосы пропускания в нисходящего и восходящего субкадре:

SIMPLE простой способ обработки запросов основываясь на FCFS RTPS процедура обработки запросов с акцентом на приложения реального времени MBQoS запросы обслуживаются в строгом приоритетном порядке

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

Использование существующих ns-3 моделей задержки и потерь при распространении радио волн, а также ns-3 mobility models

Point-Multi-Point (PMP) режим и режим WirelessMAN-OFDM физического уровеня Первоначальное расположение объектов Инициализация потоковых сервисов Управление соединением Транспортная инициализация UGS, rtPS, nrtPS, и BE соединения

Следующие аспекты на данный момент не представлены в модели но являются хорошими темами для будущих расширений модели

OFDMA физический уровень Адаптация соединения Mesh топологии ARQ ertPS соединения Подавление заголовка пакета

Использование моделей WimaxВ основном пользователи, которые пишут скрипт для симулятора ns3, взаимодействуют с

WiMAX моделями через справочник API и публично объявленные атрибуты модели.API - это набор готовых классов, процедур, функций, структур и констант, предоставляемых

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

Справочник API описывается в src/wimax/helper/wimax-helper.{cc,h}.Пример src/wimax/examples/wimax-simple.cc содержит некоторый основной код как

настроить модель

switch (schedType) { case 0: scheduler = WimaxHelper::SCHED_TYPE_SIMPLE; break; case 1: scheduler = WimaxHelper::SCHED_TYPE_MBQOS; break; case 2: scheduler = WimaxHelper::SCHED_TYPE_RTPS; break; default: scheduler = WimaxHelper::SCHED_TYPE_SIMPLE; }

NodeContainer ssNodes;NodeContainer bsNodes;

ssNodes.Create (2);bsNodes.Create (1);

WimaxHelper wimax;

NetDeviceContainer ssDevs, bsDevs;

ssDevs = wimax.Install (ssNodes, WimaxHelper::DEVICE_TYPE_SUBSCRIBER_STATION, WimaxHelper::SIMPLE_PHY_TYPE_OFDM, scheduler);bsDevs = wimax.Install (bsNodes, WimaxHelper::DEVICE_TYPE_BASE_STATION, WimaxHelper::SIMPLE_PHY_TYPE_OFDM, scheduler);

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

Для примера, различных вариантов использования Install пример src/wimax/examples/wimax-multicast.cc показывает как указать параметры канала или модели распространения не по умолчанию.

channel = CreateObject<SimpleOfdmWimaxChannel> ();channel->SetPropagationModel (SimpleOfdmWimaxChannel::COST231_PROPAGATION);ssDevs = wimax.Install (ssNodes, WimaxHelper::DEVICE_TYPE_SUBSCRIBER_STATION, WimaxHelper::SIMPLE_PHY_TYPE_OFDM, channel, scheduler);Ptr<WimaxNetDevice> dev = wimax.Install (bsNodes.Get (0), WimaxHelper::DEVICE_TYPE_BASE_STATION, WimaxHelper::SIMPLE_PHY_TYPE_OFDM, channel, scheduler);

Мобильность также поддерживается как и в моделях Wifi, смотрите src/wimax/examples/wimax-multicast.cc.

Другой важной концепцией в WiMAX это сервисный поток. Это однонаправленный поток пакетов с установленными параметрами QoS, такие как приоритет трафика, размер, тип запроса полосы пропускания и т. д. Базовая станция отвечает за выдачу идентификаторов потока услуг и сопоставления их с WiMAX соединений. Следующий код из смотрите src/wimax/examples/wimax-multicast.cc показывает, как это настраивается

ServiceFlow MulticastServiceFlow = wimax.CreateServiceFlow (ServiceFlow::SF_DIRECTION_DOWN, ServiceFlow::SF_TYPE_UGS, MulticastClassifier);

bs->GetServiceFlowManager ()->AddMulticastServiceFlow (MulticastServiceFlow, WimaxPhy::MODULATION_TYPE_QPSK_12);

WimaxNetDevice интенсивно использует нс-3 Атрибуты подсистемы для настройки и управления значений по умолчанию. В настоящее время, около 60 атрибутов хранятся в этой системе. Для примера, класс ns-3::SimpleOfdmWimaxPhy экспортирует такие атрибуты:

NoiseFigure: Потери (Дб), в отношении сигнал шум из-за не идеальности в приемнике.TxPower: Мощность передачи (Дб).G: Отношение процессорного времени к полезному времениtxGain: Коэффициент передачи (Дб).RxGain: Коэффициент приема (Дб).Nfft: Размер быстрого преобразование ФурьеTraceFilePath: Путь к директории содержащей SNR в файлах BlcER.Для получения полного перечня атрибутов обратитесь к странице Doxygen, которая содержит

полный лист всех атрибутов для ns-3.

WiMAX анализ трафикаNs-3 имеет изощрённую инфраструктуру анализа трафика, которая позволяет пользователям

подключить уже существующие источники информации о трафике, или определить и экспортировать новые. Многие пользователи ns-3 используют встроенные инструменты анализа трафика Pcap или Ascii

AsciiTraceHelper ascii;WimaxHelper wimax;wimax.EnablePcap ("wimax-program", false);wimax.EnableAsciiAll (ascii.CreateFileStream ("wimax-program.tr");

В отличии от других вспомогательных инструментов настройки модели, анализаторы трафика имею особый режим EnableAsciiForConnection(),который ограничивает ascii анализ трафика, который ограничивает ASCII анализатор для конкретного устройства и соединения. Анализатор получает информацию о пакетах с физического уровня WiMAX, от сетевых устройств и от моделей очередей. Полный перечень источников информации о трафике можно увидеть в Doxygen trace sources.

WiMAX MAC модельМодель WiMAX в ns3 являет собой попытку точно реализовать выполнение MAC и PHY уровня

стандарта IEEE 802.16 с топологией Point-to-Multipoint (PMP) и WirelessMAN-OFDM физическим уровнем. Модель состоит в основном из трех уровней:

-Подуровень конвергенции (CS-MAC)-Основной подуровень (MAC-CPS)-Физический уровень (PHY)Подуровень конвергенции (CS-MAC)Подуровень конвергенции (CS) реализован с модулем Packet CS, предназначенный для работы с

пакетными протоколами на более высоких уровнях. Подуровень конвергенции отвечает за получение пакетов с более высокого уровня и от других станций, за классификацию пакетов соответствующих соединений (или сервисных потоков) и за обработку пакетов. Он хранит карту транспортных связей для сервисных потоков. Это позволяет MAC CPS определения параметры качества обслуживания (QoS), связанные с транспортным соединением и обеспечить QoS требования. Подуровень конвергенции в ns-3 в настоящее время использует IP-классификатор.

IP пакетный классификаторIP пакетный классификатор используется для преобразования входных пакетов определенного

соединения, основываясь на наборе критериев. Классификатор поддерживает лист правил преобразования, который ассоциируется с IP потоком одного из сервисных потоков. Анализируя IP и TCP/UDP заголовки анализатор будет добавлять входящие пакеты в очередь соответствующего WiMAX соединения. Класс IpcsClassifier и класс IpcsClassifierRecord осуществляют модуль классификатора для абонентских и базовых станций.

Основной подуровень MAC Основной подуровень MAC– это подуровень IEEE 802.16 MAC, который выполняет основные

функции. Модуль выполнен с топологией Point-Multi-Point (PMP). В PMP режиме БС отвечает за управление связью среди множества АС. Ключевые функции MAC CPS включают разбиение на кадры и адресацию, генерация MAC управляющих сообщений, инициализация и регистрация АС, управление сервис потоками, управление полосой пропускания и планирование услуг. Класс WimaxNetDevice представляет собой WiMAX сетевое устройство MAC уровня. Этот класс расширяет класс NetDevice ns3 API, что предоставляет абстрактное сетевое устройство. Класс WimaxNetDevice дальше расширяется на BaseStationNetDevice и SubscriberStationNetDevice класс, описывающий MAC уровень БС и АС,

соответственно. Кроме этих главных классов, ключевые MAC функции распределены по другим классам.

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

времени. Далее кадры подразделяется на нисходящие (DL) и восходящие (UL) субкадры. Модуль выполняется в режиме дуплексной связи с временным разделением (TDD), где DL и UL выполняются на одной частоте, но разделены по времени. Последовательность пакетов DL и UL распределяются в DL и UL субкадрах, соответственно. Начиная со стандарта позволяющего групповую передачу и прием пакетов в данном DL или UL интервалах, единицей передачи на MAC уровне является последовательность пакетов. Модуль обеспечивает выполнение специальные структуры данных PacketBurst, для этих целей. Последовательность пакетов это по существу список пакетов. БС в нисходящем и восходящем канале реализует процедуру запросов полосы пропускания с помощью классов BSScheduler и UplinkScheduler это соответствует созданию DL и UL субкадров, соответственно. В случае DL, субкадр симулирует передачу последовательности пакетов (пример PacketBurst). В случае UL, субкадр разделяет согласно времени, на слоты. АС передают последовательности пакетов в этих слотах, за тем выравнивая граничные слоты. Кадр делится на целое число символов и Физических слотов (PS) который помогает управлять полосой пропускания более эффективно. Число символов в кадре зависит от низ лежащего физического уровня. Размер DL и UL групп определяется в единицах символов.

Доступ к сети и инициализацияФаза сетевого входа и инициализации обычно делится на две под фазы, (1) сканирование и

синхронизация и (2) начальный выбор диапазона. Вся фаза выполняется LinkManager компонентами АС и БС. Как только АС захочет соединиться с сетью, он сканирует нисходящую частоту и ищет подходящий канал. Поиск заканчивается тогда, когда определяется PHY кадр. Следующий шаг, установить синхронизацию с БС. АС принимает DL-MAP сообщение, и продолжает синхронизацию пока не примет DL-MAP и дескриптор нисходящего потока (DCD). После установления синхронизации, АС ожидает дескриптор восходящего канала (UCD) чтобы получить параметры восходящего канала. После получения первая полу фаза выполнена. С выполнением синхронизации, АС ожидает UL-MAP, содержащий разрешение передачи в определенном временном слоте, эта процедура называется первичной регистрацией в сети. Этот слот предоставляется БС Uplink Scheduler в регулярных интервалах. Теперь этот интервал установлен в 0,5 мс, однако пользователь может изменять его значение в скрипте симуляции.

Соединение и адресацияВсе коммуникации на MAC уровне осуществляются с точки зрения соединений. Стандарт

определяет соединение, как однонаправленные преобразования между MAC объектами АС и БС для передачи трафика. Стандарт определяет два типа соединений: управляющее соединение для передачи сообщений управления и транспортное соединение для передачи данных. Соединение идентифицируется 16 битным идентификатором соединения (CID). Класс WimaxConnection и класс Cid выполняют соединение и CID, соответственно. Замете что каждое соединение имеет собственную очередь передачи, где пакеты для передачи, относящиеся к этому соединению, ставятся в очередь. Компонент БС ConnectionManager отвечает за создание соединений и управление ими для всех АС.

Два ключевых управляющих соединения, описанные стандартом, а именно Basic и Primary управляют соединениями, создаваемые и распределяемые во время процесса выбора диапазона АС. Basic соединение играет важную роль на протяжении всей работы АС, это потому что все DL и UL (unicast) допуски на использование диапазона частот используют АС Basic CID. В дополнение к управлению соединениями, АС могут иметь одного или нескольких транспортных соединений для передачи пакетов данных. Компонент АС Connection Manager управляет соединениями связанными с АС. Как описывалось стандартом, управляющее соединение двунаправленное, то есть пара нисходящего и восходящего соединения представлено одинаковым CID. Эта возможность реализована таким образом, что одно соединение (в направление DL) создается БС и после получения CID АС затем создает идентичное соединение (в направление UL) с тем же CID.

Службы доставки данныхМодуль поддерживает службы доставки данных описанного в стандарте 802.16-2004. Название

служб ассоциируется с типом планирования запросов на предоставление ресурсов. Unsolicited Grant Service (UGS) – доставка без требования, спроектирован для приложений

реального времени с фиксированным размером пакетов.

Real-Time Polling Services (rtPS) – доставка в реальном времени с переменной скоростью. Non Real-Time Polling Services (nrtPS) – доставка вне реальном времени с переменной

скоростью. Best Effort (BE) – доставка по мере возможности, спроектирован для приложений, не

требующих минимальных гарантий полосы пропускания (HTTP, Email)

Рисунок 2 Блок-схема модуля WiMAXТипы планирования запросов ведут себя по-разному в зависимости от того сколько

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

WiMAX модель планирования запросов на доступ к ресурсам в нисходящем потокеПланирование запросов нисходящего потока на БС решает, между каким АС распределить

нисходящий поток основываясь на QoS параметрах связанных с сервисными потоками (или типом планирования запросов) и запрошенной полосой пропускания от АС. Планировщик запросов нисходящего потока вместе с Bandwidth Manager выполняют весь функционал планирования. Стандарт определяет до четырех типа планирования запросов (BE, UGS, rtPS, nrtPS) для приложений с различными требованиями QoS. Сервисные потоки этих планировщиков ведут себя по-разному в зависимости от того сколько они требуют полосы пропускания, а также сколько полосы пропускания занято. Модуль поддерживает все четыре типа планирования. Каждый сервисный поток ассоциируется только с одним транспортным соединением и одним планировщиком. Параметры QoS связанные с сервисным потоком фактически описывают тип планирования запросов, к которому он принадлежит. Стандартные QoS параметры, поддерживаемые в UGS, rtPS, nrtPS и BE сервисах, указаны в таблицах

111a до 111d в поправке 802.16e. Когда сервисный поток создан, планировщик рассчитывает необходимые параметры. Текущий WiMAX модуль предоставляет три различных типа планирования запросов.

Первый SIMPLE основанный на приоритетах First Come First Serve (FCFS). Для сервисов реального времени (UGS и rtPS) БС тогда выделяет допуски\опросы на регулярной основе в соответствии с рассчитанными интервалами. Для сервисов не реального времени (nrtPS и BE) при наличии потоков сервисов реального времени гарантируется только минимум резервирования полосы пропускания. Замете что не все эти параметры используются планировщиком восходящего потока. Также отметим, что в настоящее время поддерживаются только сервисные потоки с фиксированным размером пакета, так как в настоящее время в симуляторе созданы сценарии с OnOff приложения с фиксированным размером пакета. Этот планировщик выполняется классами BSSchedulerSimple и UplinkSchedulerSimple.

Второй похож на первый тип планирования. Все rtPS соединения способны передать все пакеты в очередь, согласно доступной полосе пропускания. Контроль над перегрузками в сети реализован на перераспределение доступной полосы пропускания ко всем rtPS, которые имеют хотя бы один пакет для передачи. Остальная полоса пропускания выделяется nrtPS и BE соединениям. Этот тип планирования выполняются классами BSSchedulerRtps и UplinkSchedulerRtps.

Третий тип планирования восходящего потока использует три очереди, низко приоритетная, средне приоритетная и высоко приоритетная очередь. Планировщик выстраивает точный приоритетный порядок, от высоко приоритетной к низко приоритетной очереди. Низко приоритетная очередь содержит в себе запросы BE сервисного потока. Средняя очередь содержит запросы отправленные rtPS и nrtPS соединениями. rtPS и nrtPS запросы могут перемещаться в высоко приоритетную очередь гарантируя что их требования QoS будут выполнены. Кроме запросов перемещаемые из средней очереди, высокоприоритетная очередь хранит UGS запросы и индивидуальные запроса, которые должно быть запланировано в следующем кадре. Чтобы гарантировать, максимальны требования по задержке, БС определяет крайний срок каждому rtPS запросу полосы пропускания в средней очереди. Этот тип планирования реализуется классом UplinkSchedulerMBQoS.

WiMAX модель планирования исходящего тарфика Кроме типов планирования запросов полосы пропускания нисходящего потока, на сторонах БС и

АС имеется планирование исходящего трафика (BSScheduler и SSScheduler). Это планирование решает, какой пакет из исходной очереди будет передан в том или ином выделенном ресурсе. Планирование исходящего трафика на БС планирует нисходящий трафик. Так же планирование исходящего трафика на АС планирует пакеты восходящего трафика. Планирование исходящего трафика реализованы как FCFS, так они распределяют ресурсы, начиная с приоритетного сервиса к низко приоритетному сервису (UGS> rtPS> nrtPS> BE).

WiMAX PHY модель Для физического уровня, мы выбрали Wireless MAN OFDM PHY спецификацию, как наиболее

соответствующую для выполнения, так как эта схема выбрана WIMAX форумом. Эта спецификация спроектирована для передачи сигнала без прямой видимости (NLOS), включая фиксированный и мобильный широкополосный беспроводной доступ. Предложенная модель использует FFT=256. Физический уровень поддерживает все семь модуляций и кодирующих схем в спецификации Wireless MAN-OFDM. Физический уровень соединяет в себе две части: канальную и физическую модель.

Канальная модельКанальную модель мы предлагаем выполнить с помощью класса SimpleOFDMWimaxChannel,

который расширяет wimaxchannel класс. Объект канал имеет собственную структуру называемую m_phyList который обрабатывает все физические устройства соединенные с ним. Когда физическое устройство отправляет пакет (FEC Block) в канал, канал обрабатывает пакет, и тогда для каждого физического устройства соединенного с ним, он рассчитывает задержку распространения, соответствующие путевые потери в данной модели распространения и в конечном счете отправляет пакет к принимаемому устройству.

Класс channel использует метод GetDistanceFrom() для расчета расстояния между двумя физическими объектами согласно их 3D координатам. Задержка рассчитывается как задержка = расстояние/С, где С это скорость света. Мы имеем в использовании три различных модели распространения, для расчета путевых потерь: FRIIS, LOG-DISTANCE и COST-Hata-Model.

Физический уровень

Физический уровень выполняет две главные операции: (1) Он принимает пакеты с канала и отправляет их на MAC уровень, (2) принимает пакеты с МАС уровня и передает их в канал. В порядке уменьшения сложности симуляции WiMAX физического уровня, мы выбрали автономную модель части физического уровня. Более подробно мы развили OFDM симулятор в генерировании файлов трассировки используя процесс приема в оценке, могут ли FEC блоки быть корректно декодированы или нет.

Процесс передачи: группа пакет это набор WiMAX MAC PDUs. В процессе отправки, группа пакетов преобразуется в битовый поток и тогда разделяется на маленькие FEC блоки, которые затем отправляются в канал с мощностью равной P_tx.

Процесс приема: процесс приема включает в себя следующие операции:1 – Прием FEC блока с канала. 2 – Расчет уровня шума. 3 – Оценка отношения сигнал шум.

(SNR) 4 – Оценка возможности правильного декодирования FEC блока. 5 – Связывание принятых FEC блоков и восстановление первоначальной группы пакетов. 6 – Отправка группы пакетов на верхний уровень.

Разработан процесс оценки, если FEC блок может быть корректно принят или не использовать предварительную генерацию файлов мониторинга. Файлы мониторинга генерируются внешним OFDM симулятором (будет описано позже). Класс называется SNRToBlockErrorRateManager обрабатывающий репозиторий содержащий семь файлов мониторинга (одно для каждой схемы модуляции и кодирования). Репозиторий специфичными для конкретной модели канала.

Файлы мониторинга создают шесть колонок. Первая колонка предоставляет значение SNR (1), тогда как другие колонки дают соответственно значение битовой ошибки BER (2), значение блоковых ошибок BlcER (3), стандартное отклонение BlcER, и доверительный интервал (4 и 5). Эти файлы мониторинга загружаются в память объектом SNRToBlockErrorRateManager в начале симуляции.

Теперь Первый процесс использует первую и третью колонку для определения принят ли FEC блок корректно. Тогда физический уровень принимает пакет с SNR равному SNR_rx и спрашивает SNRToBlockErrorRateManager возвращать ли соответствующий блок ошибок BlcER. Тогда генерируется случайное число RAND между 0 и 1. Если RAID больше чем BlcER, тогда блок FEC принят корректно, иначе блок рассматривается ошибочным и игнорируется.

Модуль предоставляет значения по умолчанию SNR в библиотеке default-traces.h. Библиотека была сгенерирована External WiMAX OFDM симулятором. Симулятор основывается на внешних математических и сигнальных процессах библиотеки IT++ и включает: случайную генерацию блоков, кодер Рида Соломона, сверточный код, перемежение, 256 FFT-based OFDM модулятор, симулятор разветвленных каналов и эквалайзер. Разветвленный канал моделируется, используя TDL_channel класс IT++ библиотеки.

Пользователь может конфигурировать модуль, используя их собственный trace генератор другого OFDM симулятора или в идеале выполненного экспериментально на реальном оборудовании. Для этих целей, должен быть, предоставлен путь к репозиторию содержащий файлы trace. Если нет репозитория предоставляющего trace файлы, будет загружен файл default-traces.h. Действующие репозитории содержат 7 файлов, один на каждую схему модуляции и кодирования.

Названия файлов должны соблюдать следующий формат modulation0.txt для modulation 0, modulation1.txt для modulation 1 и.т.д. Формат файла должен выглядеть следующим образом SNR_value1 BER Blc_ER STANDARD_DEVIATION CONFIDENCE_INTERVAL1 CONFIDENCE_INTERVAL2 SNR_value2 BER Blc_ER STANDARD_DEVIATION CONFIDENCE_INTERVAL1 CONFIDENCE_INTERVAL2… … … … …… … … … …