Автоматизированное развертывание службы телефонии Интернет-протокола на беспилотных летательных аппаратах с использованием виртуализации сетевых функций

Summary

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

Abstract

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

Чтобы продемонстрировать практическую целесообразность использования технологий NFV на платформах БПЛА, представлен протокол для создания функциональной среды NFV на основе технологий с открытым исходным кодом, в которой набор небольших БПЛА поставляют вычислительные ресурсы, поддерживающие развертывание умеренно сложных сетевых служб. Затем в протоколе подробно описаны различные шаги, необходимые для поддержки автоматизированного развертывания службы телефонии интернет-протокола (IP) по сети взаимосвязанных БПЛА, используя возможности настроенной среды NFV. Результаты экспериментов свидетельствуют о надлежащей работе службы после ее развертывания. Хотя в протоколе основное внимание уделяется определенному типу сетевого обслуживания (т.е. IP-телефонии), описанные шаги могут служить общим руководством для развертывания других типов сетевых служб. С другой стороны, в описании протокола рассматривается конкретное оборудование и программное обеспечение для настройки среды NFV (например, конкретные однобортные компьютеры и программное обеспечение с открытым исходным кодом). Использование других аппаратных и программных платформ может быть осуществимо, хотя конкретный аспект конфигурации среды NFV и развертывание службы могут представлять различия в отношении тех, которые описаны в протоколе.

Introduction

Одна из самых желанных целей в новую эру мобильной связи (наиболее известная как^5-е мобильное поколение или 5G) заключается в том, чтобы иметь возможность предоставлять надежные услуги в области информационных технологий в ситуациях, когда первичная телекоммуникационная инфраструктура может быть недоступна (например, в связи с чрезвычайной ситуацией). В этом контексте БПЛА все большее внимание уделяется научному сообществу в связи с присущей им универсальностью. Существует множество работ, которые используют эти устройства в качестве краеугольного камня для предоставления широкого спектра услуг. Например, в литературе проанализирована способность этих устройств для создания инфраструктуры воздушной связи для размещения мультимедийных услуг^1,2,3. Кроме того, предыдущие исследования показали, как сотрудничество между несколькими БПЛА может расширить функциональность различных услуг связи, таких как наблюдение⁴, совместный поиск и спасение^5,6,7,8, или агробизнеса⁹.

С другой стороны, технология NFV приобрела большое значение в операторах связи как один из ключевых возможностей 5G. NFV представляет собой парадигматическое изменение в отношении телекоммуникационной инфраструктуры путем облегчения нынешней зависимости сетевой техники от специализированного оборудования за счет софтваризации сетевых функций. Это позволяет гибко и гибко развертывать новые типы коммуникационных служб. С этой целью Европейский институт стандартов телекоммуникаций (ETSI) сформировал группу спецификаций для определения архитектурной структуры NFV¹⁰. Кроме того, ETSI в настоящее время хостов с открытым исходным кодом Mano (OSM) группа¹¹, которая отвечает за разработку NFV управления и оркестровки (MANO) программного обеспечения стек в соответствие с определением архитектурной основы ETSI NFV.

С учетом всех вышеупомянутых соображений в настоящее время изучается синергическая конвергенция бПЛА и технологий NFV при разработке новых сетевых приложений и услуг. Это иллюстрируется несколькими научно-исследовательскими работами в литературе, которые указывают на преимущества этих типов систем^14,15,16, определить проблемы этой конвергенции и ее недостающие аспекты, выделить будущие исследования линий по этой теме¹⁷, и настоящее пионером решений, основанных на технологиях с открытым исходным кодом.

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

Несмотря на преимущества, реализация этой точки зрения представляет собой набор фундаментальных проблем, которые необходимо тщательно решать, таких как соответствующая интеграция этих вычислительных платформ в качестве инфраструктуры NFV, используя существующий стек программного обеспечения NFV, так что служба оркестровки NFV может развертывать виртуальные функции на БПЛА; ограничения с точки зрения вычислительных ресурсов, предоставляемых вычислительными платформами, поскольку беспилотные летательные аппараты, перевозящие их, обычно могут представлять ограничения с точки зрения размера, веса и вычислительной мощности оборудования полезной нагрузки; правильное размещение виртуальных функций на БПЛА (т.е. выбор лучшего кандидата Накра для развертывания конкретной виртуальной функции); поддержание контрольной связи с БПЛА в целях управления жизненным циклом ВНФ, несмотря на потенциально прерывистую доступность сетевых коммуникаций с ними (например, вызванных ограничениями подвижности и аккумуляторов); ограниченное время работы БПЛА из-за их потребления батареи; и миграция виртуальных функций, когда БПЛА необходимо заменить из-за усталости батареи. Эти преимущества и проблемы подробно описаны в предыдущей работе^18,19, которая включает в себя разработку системы NFV, способной поддерживать автоматизированное развертывание сетевых функций и услуг на платформах БПЛА, а также проверку практической осуществимости этой конструкции.

В этом контексте в настоящем документе основное внимание уделяется описанию протокола, позволяющего автоматизированно развертывать умеренно сложные сетевые службы по сети БПЛА с использованием стандартов NFV и технологий с открытым исходным кодом. Для иллюстрации различных этапов протокола представлена перепланировка эксперимента, представленного в Nogales et al.^19, состоящего из развертывания службы IP-телефонии. Для воспроизводимости этой работы реальный полет считается факультативным в представленной процедуре, а результаты работы получены с помощью БПЛА на земле. Заинтересованные читатели должны иметь возможность реплицировать и проверять выполнение протокола, даже в контролируемой лабораторной среде.

На рисунке 1 иллюстрируется сетевой сервис, предназначенный для этой процедуры. Эта сетевая служба построена как состав конкретных единиц softwarization (классифицируется в парадигме NFV как виртуальные сетевые функции, или VNFs) и обеспечивает функциональность службы IP-телефонии для пользователей в непосредственной близости от БПЛА. ВНФ, составляющий услугу, определяется следующим образом:

• Точка доступа VNF (AP-VNF): Этот VNF предоставляет точку доступа Wi-Fi к оборудованию конечных пользователей (т.е. IP-телефонам в этом эксперименте).
• IP-телефонии сервер VNF (IP-телефония-сервер-VNF): Он отвечает за управление вызова сигнальных сообщений, которые обмениваются между IP-телефонов для установления и прекращения голосового вызова.
• Система доменных имен VNF (DNS-VNF): Этот VNF предоставляет услугу разрешения имен, которая обычно необходима в услугах IP-телефонии.
• Маршрутизатор доступа VNF (AR-VNF): обеспечивает функции маршрутирования сети, поддерживая обмен трафиком (т.е. сигнализация вызова в этом эксперименте) между IP-телефонами и доменом оператора связи.
• Основной маршрутизатор VNF (CR-VNF): обеспечивает функции маршрутирования сети в домене оператора связи, предлагая доступ к услугам оператора (т.е. серверу IP-телефонии) и внешним сетям передачи данных.

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

Protocol

1. Предварительные реквизиты для эксперимента

1. Установите стек программного обеспечения управления и оркестровки (MANO), предоставленный проектом MANO открытого исходного кода (OSM). В частности, в этом эксперименте используется OSM Release FOUR²⁰, который может быть выполнен на одном серверном компьютере или в виртуальной машине (VM), выполняющей требования, указанные сообществом OSM: Ubuntu 16.04 в качестве операционной системы (64-битное изображение варианта), два центральных процессорных блока (CPUs), 8 ГБ случайной памяти доступа (RAM), 40 ГБ накопительного диска и единый сетевой интерфейс с доступом в Интернет. Процедура установки OSM Release FOUR вместе с его техническими деталями доступна в онлайн-документации, предоставленной сообществом OSM^21.
2. Настройка платформы облачных вычислений, обеспечивающая функции виртуального менеджера инфраструктуры (VIM), совместимого с OSM Release FOUR. Для этого эксперимента используется релиз OpenStack Ocata^22, работающий в VM с Ubuntu 16.04 в качестве операционной системы, четырех процессоров, 16 ГБ оперативной памяти и 200 ГБ накопителя. В эксперименте VIM управляет инфраструктурой NFV (NFVI), интегрированной двумя высокопрофильными серверными компьютерами, каждый из которых имеет Ubuntu 16.04 в качестве операционной системы, восемь процессоров, 128 ГБ оперативной памяти и 4 ТБ накопительных диска. Вся информация о том, как настроить платформу облачных вычислений, включена в руководство по установке, включенное в документацию OpenStack^23. Эта облачная платформа называется основной облачной платформой.
3. Настройка дополнительной платформы облачных вычислений для БПЛА называется облачной платформой Для Беспилотных летательных аппаратов.
   1. Убедитесь, что эта платформа оснащена VIM на основе openStack релиз Ocata. В этом случае ресурсы, используемые установкой VIM, являются Ubuntu 16.04 в качестве операционной системы, два процессора, 6 ГБ оперативной памяти, 100 ГБ диска для хранения и внешний адаптер WI-Fi USB.
   2. NFVI интегрирована в эту облачную платформу состоит из одного фиксированного вычислительного сервера (Ubuntu 16.04 в качестве операционной системы, восемь процессоров, 8 ГБ оперативной памяти, 128 ГБ накопительного диска, и внешний адаптер Wi-Fi USB) и три однобортных компьютера (SBCs). Последние обеспечивают аппаратную платформу, которая может быть легко на борту БПЛА. См. раздел 3 для процедуры настройки облачной платформы БПЛА с этими устройствами в качестве вычислительных узлов.
4. Оборудуйте каждый SBC оборудованием питания батареи, прикрепленным сверху (HAT), чтобы обеспечить работу этих агрегатов, даже когда они находятся в движении, перевозимые БПЛА.
   ПРИМЕЧАНИЕ: Шаг 1.5 не является обязательным, потому что предоставление сетевой службы в эксперименте не зависит от наличия БПЛА. Кроме того, SBCs перевозятся как полезная нагрузка БПЛА и никаких других дополнительных соединений (например, Ethernet или USB) не требуется, потому что сетевые связи, необходимые для надлежащей работы IP-телефонии службы предоставляются SBCs, через их Wi-Fi адаптеры, и блок питания обеспечивается питания HAT упомянутых в шаге 1.4.
5. Прикрепите каждый SBC как полезную нагрузку БПЛА через фиксирующий аксессуар. В ходе этого эксперимента были выбраны три коммерческих БПЛА для транспортировки вычислительных единиц, предлагаемых SBCs.
6. Выберите два беспроводных телефона голосовой связи (VoIP), которые поддерживают стандарт беспроводной связи IEEE 802.11b; эта модель обеспечивает беспроводную связь через Wi-Fi. В качестве альтернативы голосовой вызов может быть выполнен с помощью приложений софтфона, таких как Linphone²⁴ или Jitsi²⁵.
7. В качестве экспериментального требования убедитесь в наличии: a) связи слоя-3 между стеком программного обеспечения OSM и каждым из ВИМ-си, с тем чтобы можно было организовать организованное развертывание сетевой службы, разработанной для этого эксперимента, b) между OSM и VNF на каждой облачной платформе для поддержки процедур конфигурации VNF, и c) связь слоя-3 между VNFs, работающая на каждом VIM, чтобы обеспечить надлежащее функционирование сетевого сервиса.
8. Все содержимое, необходимое для проведения эксперимента, содержится в публичном хранилище экспериментов http://vm-images.netcom.it.uc3m.es/JoVE/.

2. Проверка функциональности агрегатов softwarization с помощью эмуляции

ПРИМЕЧАНИЕ: Чтобы доказать соответствующую работу сетевой службы эксперимента (см. рисунок 1) в реалистичных условиях развертывания, была использована специально разработанная эмуляция на основе контейнеров Linux²⁶ и ns-3^27. Эта платформа позволяет эмуляции многохэмных воздушных связей и определения характеристик этих связей (например, длина беспроводных каналов связи, структура потерь пакетов данных, радиотехнология, используемая в беспроводной связи и т.д.). Таким образом, в этом разделе протокола описаны шаги, которым следует следовать для проверки надлежащей работы службы IP-телефонии в реалистичных условиях беспроводной связи через эмуляционную платформу.

1. Загрузите эмуляционную платформу из репозитория эксперимента. Платформа доступна в виде виртуальной машины под названием "uav-nfv-jove-experiment.qcow", совместимая с технологией виртуализации KVM²⁸. Эта машина содержит заранее созданный шаблон, который эмулирует сетевой сервис и сценарий мульти-БПЛА, представленный на рисунке 1, и пользователя с привилегиями администратора, способными выполнять этот шаблон.
   ПРИМЕЧАНИЕ: По умолчанию, следующие шаги автоматически выполняются при запуска художня платформы эмуляции: а) виртуальная среда настроена таким образом, чтобы система эмуляции сети (т.е. сетевые интерфейсы, Мосты Linux^29); b) создаются контейнеры Linux, представляющие различные физические компоненты испытательного листа (т.е. SBCs и фиксированный вычислительный сервер для облачной платформы БПЛА, а также вычислительный сервер для основной облачной платформы; и c) функции, предоставляемые различными VNF службы IP-телефонии (т.е. точки доступа, маршрутизаторы, DNS служить, и IP-телефонии сервера) развернуты в качестве Linux контейнеров над их соответствующих эмулированных SBCs и вычислительных серверов.
2. Перед процессом проверки навяжете эмулированную многохмэмовую воздушную сеть с помощью тренажера ns-3, чтобы обеспечить связь между различными участниками сети. Эта процедура будет подражать реалистичной беспроводной связи, которая происходит в сценарии, изображенном на рисунке 1 (т.е. Wi-Fi ad-hoc сети, которая позволяет обмен данными между узлами облачной платформы БПЛА и беспроводных сетей, предлагаемых двумя точками доступа Wi-Fi, предоставляемых в службе).
   1. Создайте многохортовые воздушные сети. Для этой цели, выполнить multi-hop-aerial-net.sh скрипт (доступны в эмуляции платформы машины) с помощью следующей команды: sudo ш / дома / jovevm / скриптов / мульти-хоп-воздушный-net.sh и multi-hop-aerial-net trace.log 2 и 1 и. Эта команда изображает след моделирования в указанном файле журнала, чтобы включить отладку в случае ошибок.
   2. Проверьте, успешно ли создана сеть. С этой целью проверьте, получили ли Linux Контейнеры "IP-phone-a" и "IP-phone-b" (иллюстрированные на рисунке 1 как оборудование для конечных пользователей, которое подключается к AP-VNF) получили IP-адрес через сервис DHCP, который доступен только через многохмнаправленную воздушную сеть. Состояние контейнера Linux, выполняемого в машине эмуляции, а также их IP-адресов, можно проверить с помощью списка команд lxc.
3. Проверьте способность эмулированной сетевой службы обрабатывать сигнальные сообщения, необходимые для настройки вызова IP-телефонии. Для этого как "IP-телефон-а" и "IP-телефон-б" Linux контейнеры установили "SIPp" инструмент³⁰. "SIPp" предоставляет функциональность для эмуляции IP-телефона, создавая упомянутые сигнальные сообщения, отправляя их на сервер IP-телефонии и обрабатывая ответ для проверки правильной работы последнего.
   1. Выполните сценарий test-signaling.sh в обоих контейнерах, который запускает инструмент "SIPp" для генерации и отправки сигнальных сообщений на IP-телефонию-сервер-VNF.
   2. Проверьте экран сценария, предоставленный выполнением предыдущего шага. Прием ответа "200" показывает надлежащее функционирование IP-телефонии-сервера-VNF.
4. Проверка того, что сетевая служба может обрабатывать трафик данных, который генерируется во время ip-телефонии вызова. Для этого в linux-контейнерах "IP-phone-a" и "IP-phone-b" устанавливается инструмент планирования потока "Trafic".
   1. Выполните следующую команду, чтобы запустить серверный агент Trafic: lxc exec IP-phone-b sh called-party.sh.
   2. Затем выполните следующую команду, чтобы запустить агента клиента Trafic и получить сетевую статистику: lxc exec IP-phone-a sh caller.sh. Трафик данных, имитирующий голосовой вызов, прекращается после 60 с. Скрипт отображает сообщение о подтверждении и наиболее значительные показатели производительности, касающиеся голосового трафика.
   3. Проверьте полученные метрики и убедитесь, что служба IP-телефонии может эффективно поддерживать интерактивный голосовой разговор. Для этого см. информацию, сошедую в раздел о репрезентативных результатах.

3. Строительство облачной платформы БПЛА

1. Выберите модель SBC, которая может обеспечить подстрат виртуализации для выполнения легких VNF. Технические характеристики устройств SBC, используемых в ходе эксперимента: четыре процессора, 1 ГБ оперативной памяти и 32 ГБ накопителя. Кроме того, каждый SBC имеет три сетевых интерфейса: интерфейс Ethernet, интегрированный интерфейс Wi-Fi и внешний адаптер Wi-Fi USB.
2. Подготовьте SBC к последующей интеграции в облачную платформу БПЛА.
   1. Установите Ubuntu Mate³² 16.04.6 в качестве операционной системы, учитывая, что пакеты установки OpenStack включены в этот дистрибутив Linux.
   2. Установите и назначайте необходимые пакеты, указанные в документации OpenStack^33, чтобы позволить SBCs выступать в качестве вычислительных узлов облачной платформы БПЛА. Следуя предыдущему руководству, включите использование контейнеров Linux в конфигурации пакетов OpenStack. Виртуализация контейнеров используется из-за ограниченности ресурсов устройств, которые обычно могут быть на борту малогабаритных БПЛА.
   3. В SBC загрузите и выполните скрипт rpi-networking-configuration.sh,доступное в репозитории эксперимента. Этот скрипт позволяет беспроводной связи SBCs, а также необходимую конфигурацию, чтобы позволить создание виртуальных сетей, подключенных к беспроводным интерфейсам.
   4. Скачать и выполнить сценарий VIM-networking-configuration.sh,доступный в репозитории эксперимента, в хосте под управлением облачной платформы БПЛА VIM. Этот скрипт контролирует настройку беспроводной связи VIM для обмена информацией с SBCs.
      ПРИМЕЧАНИЕ: После того, как сеть хорошо настроена и VIM имеет связь с SBCs, VIM автоматически интегрирует их в облачную платформу БПЛА в качестве вычислительных единиц, способных выполнять VNF
3. Создайте зону доступности OpenStack для каждого из SBC. Это позволит развернуть каждый из легких VNF эксперимента в соответствующем блоке БПЛА. Чтобы сделать это, войдите в веб графический пользовательский интерфейс, предоставляемый VIM с учетными данными администратора, создайте зоны доступности в системе Администратора (Система) и вкладка Host Aggregates, и отспособите каждую зону доступности, чтобы добавить соответствующий хост (т.е. каждый SBC интегрирован в облачную платформу БПЛА).
4. Проверьте правильную настройку облачной платформы БПЛА. Чтобы сделать это, доступ к администратору и системе ,gt; Система Информация вкладка с тем же логином, как и в предыдущем шаге, и нажмите в разделе вычислительной службы и сетевых агентов, чтобы проверить, что статус отображаемых элементов является "живой" и "UP".

4. Настройка эксперимента

1. Загрузите изображения VNF, которые реализуют различные компоненты IP-телефонии: AP-VNF, DNS-VNF, IP-телефония-сервер-VNF, AR-VNF и CR-VNF. Эти изображения можно загрузить из репозитория эксперимента.
2. Загрузите изображения VNF на свой корреспондент VIM (т.е. AP-VNF и DNS-VNF на облачную платформу БПЛА VIM) и VoIP-VNF на основную облачную платформу VIM. Чтобы сделать это, войдите в веб графический пользовательский интерфейс, предоставляемый каждым VIM с полномочиями администратора, нажмите на кнопку Создать изображение администратора (ru) и создать изображение с помощью отображаемых форм и выбора соответствующего изображения. Этот процесс выполняется на соответствующем VIM для каждого изображения, которое было загружено на предыдущем этапе.
3. Загрузите дескрипторы VNF (VNFD) эксперимента из репозитория эксперимента. Эти дескрипторы предоставляют шаблоны, описывающие эксплуатационные требования VNF, а также политики размещения, которые указывают на зону доступности, отвечающая за размещение самого Нпф. Более подробную информацию о дескрипторах NFV можно найти в информационной модели OSM³⁴.
4. Загрузите VNFDs. Используйте веб-браузер для доступа к графическому пользовательскому интерфейсу OSM и вопийте с учетными данными администратора. Затем перетащите и опустите VNFDs во вкладку пакетов VNF.
5. Загрузите дескриптор сетевых служб (NSD) из репозитория эксперимента. Этот дескриптор представляет собой шаблон, который определяет VNFs, включающий службу, а также то, как эти VNF взаимосвязаны.
6. Загрузите NSD. Перетащите и опишите NSD во вкладку NS Packages графического пользовательского интерфейса OSM.
7. Используя графический пользовательский интерфейс OSM, добавьте учетную запись VIM для облачной платформы БПЛА VIM и основной облачной платформы VIM. Для этого получите доступ к вкладке учетных записей VIM с учетными данными администратора, нажмите на кнопку New VIM и заполните отображаемую форму запрошенной информацией. Повторите это действие для обоих VIM.

5. Выполнение эксперимента

1. Развертывание сетевого сервиса. С вкладки пакетов NS графического пользовательского интерфейса OSM нажмите на кнопку Instantiate NS NS NS, загруженную в шаге 4.6. Затем заполните отображаемую форму, указав VIM, который будет использоваться для развертывания каждого VNF, сочинения NS. Кроме того, OSM отвечает за обработку политик размещения, указанных в NNFDs, чтобы указать VIM, какая зона доступности (т.е. вычислительная единица в нашем испытательном ложе) отвечает за размещение каждого VNF. Для этого эксперимента VNF помещаются в вычислительные единицы, как показано на рисунке 1.
   ПРИМЕЧАНИЕ: В качестве альтернативного метода, OSM обеспечивает интерфейс командной строки, который позволяет прямое взаимодействие с пользователем. Пользователь, воспроизводящий этот эксперимент, может использовать интерфейс этой командной строки, вместо графического интерфейса, для выполнения различных шагов, определенных в этом протоколе, в частности, тех шагов, которые связаны с развертыванием VNF или ns дескриптора, а также развертыванием сетевого обслуживания.
2. Подождите, пока графический пользовательский интерфейс OSM не упоказывает успех развертывания сетевого сервиса.
   ПРИМЕЧАНИЕ: Работа сетевого сервиса полностью не зависит от полета БПЛА: услуга IP-телефонии может быть предоставлена, когда БПЛА летают или экономит расход батареи, расположенные на поверхности. Таким образом, шаг 5.3 является необязательным.
3. Снимите БПЛА. Зайдите в мобильное приложение и управляйте полетом каждого БПЛА, чтобы заглушить его на промежуточной высоте и избежать турбулентности, вызванной вращением двигателей близко к поверхности.
4. Подготовьте каждый из IP-телефонов для выполнения вызова.
   1. Подключите беспроводной voIP-телефон к каждой из точек доступа, предлагаемых сетевой службой. Для этой цели, указать SSID ( СервисSet Идентификатор) в меню Наконец, выберите конфигурацию сети через динамический протокол конфигурации хоста (DHCP) в меню (gt; Настройки чистых)
   2. Налажив параметры протокола инициирования сеанса (SIP), чтобы обеспечить надлежащий обмен сигнальными сообщениями с сервером IP-телефонии. В этом контексте, доступ к меню и прокси-сервера и указать название хозяина IP-телефонии сервера VNF ("dronesVoIP.net") в регистраторе и прокси-сервера и прокси-сервера. Кроме того, создайте учетную запись пользователя, вводящую имя пользователя (например, вызывающего абонента-A) в учетной записи пользователя (ru) и в разделах User.
   3. Создайте запись в телефонной книге одного из IP-телефонов, предоставляющих информацию пользователя, который должен быть вызван. Для этого выберите Меню ( и телефонная книга, добавленная вкладка входа, и заполните запрошенные параметры, которые отображаются на дисплее следующим образом: Название дисплея - caller-B; Информация о пользователях и абонент-B; Хост IP - dronesVoIP.net; Порт No 5060. Наконец, выберите опцию "Прокси" по сравнению с P2P (равный-равному).
5. Начните звонок другой стороне. Чтобы сделать это, выберите называемую партию, используя меню , телефонная книга ( и поиск вариант IP-телефона. Затем нажмите кнопку вызова. Как только другой IP-телефон начинает звонить, примите входящий вызов с помощью кнопки вызова.

6. Процедура сбора экспериментальных результатов

1. Подключите товарный ноутбук к одному из беспроводных aPs и запустите инструмент команды ping к IP-адресу телефона, подключенного к другому AP в течение 180 с. IP-адрес может быть проверен в меню (gt; Информация) информация, опция IP-адреса IP-телефона, как только соединение установлено с AP. Сохранить время кругосветного времени (RTT) измерений, перенаправление вывода, предоставляемого пинг-инструмент в файл.
2. Выполните инструмент командной строки tcpdump в одном из запущенных AP VNF для захвата трафика, обмениваемого во время IP-вызова. Сохранить этот трафик в файл, позволяющий написать флаг инструмента командной строки во время выполнения и указать имя файла.
3. Выполните новый вызов IP-телефонии. Поддерживайте вызов на желаемый период времени (например, 1 мин). Затем прекратите вызов, нажав кнопку повесить трубку одного из IP-телефонов.
4. Храните файлы, генерируемые инструментами tcpdump и ping, для дальнейшей обработки. Смотрите результаты представительства.

Representative Results

На основе данных, полученных в ходе выполнения эксперимента, в котором выполняется реальный voIP-звонок и следует за шагами, указанными протоколом для сбора этой информации, на рисунке 2 изображена совокупная функция распределения сквозной задержки, измеряемой между двумя элементами оборудования для конечных пользователей (т.е. товарным ноутбуком и IP-телефоном). Это пользовательское оборудование представляет собой два устройства, которые взаимосвязаны через AP VNF развернутой сетевой службы. Более 80% сквозных измерений задержки были ниже 60 мс, и ни один из них не превышал 150 мс, что гарантирует соответствующие метрики задержки для выполнения голосового вызова.

Рисунок 3 иллюстрирует обмен dNS и SIP сигнальными сообщениями. Эти сообщения соответствуют регистрации одного из пользователей на сервере IP-телефонии (т.е. пользователю, чей IP-телефон подключен к AP VNF, где работает инструмент«tcpdump»)и созданию голосового вызова.

Наконец, на рисунке 4 и рисунке 5 показан трафик данных, захваченный во время вызова. В частности, первый представляет собой постоянный поток голосовых пакетов, передаваемых и полученных одним из беспроводных телефонов во время вызова, в то время как последний иллюстрирует испуг в прямом направлении со средним значением ниже 1 мс.

Результаты, полученные в ходе эксперимента по показателям задержек (сквозная задержка и дрожь), удовлетворяют рекомендациям, указанным Международным союзом электросвязи - Сектором стандартизации электросвязи (ItU-T)³⁵. Соответственно, голосовой вызов прогрессировал без сбоев и хорошего качества звука. Этот эксперимент подтвердил практическую целесообразность использования технологий NFV и БПЛА для развертывания функциональной службы IP-телефонии.

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

Рисунок 2: Сквозная задержка. Представление о сквозной задержке, предлагаемой конечному оборудованию, подключенномке к НПФ AP. Для этого из измеренных образцов RTT, полученных с помощью командной линии"ping"была вычислена совокупная функция распределения сквозной задержки. Пожалуйста, нажмите здесь, чтобы просмотреть большую версию этой цифры.

Рисунок 3: Регистрация пользователей и сигнальные сообщения. Иллюстрация сигнального трафика (DNS и SIP), обмениваемого для регистрации пользователя на сервере IP-телефонии и создания и прекращения мультимедийного сеанса, поддерживающего выполнение голосового вызова. Пожалуйста, нажмите здесь, чтобы просмотреть большую версию этой цифры.

Рисунок 4: Поток голосовых пакетов. Представление голосового трафика, обмениваемого во время вызова, измеренного в одном из AP VNF. (Аббревиативы: RX и получить, RX й передать, RTP и в режиме реального времени транспортный протокол). Пожалуйста, нажмите здесь, чтобы просмотреть большую версию этой цифры.

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

Discussion

Одним из наиболее важных аспектов этого эксперимента является использование технологий виртуализации и стандартов NFV с платформами БПЛА. NFV представляет новую парадигму, направленную на разъединение аппаратной зависимости от функций сети, тем самым позволяя предоставлять эти функциональные возможности через softwarization. Соответственно, эксперимент не зависит от использования оборудования, указанного в протоколе. Кроме того, могут быть выбраны различные модели однобортных компьютеров, если они соответствуют габаритам и транспортной емкости БПЛА и поддерживают контейнеры Linux.

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

С другой стороны, эксперимент предусматривает взаимодействие двух различных вычислительных платформ (наоборот, облачной платформы БПЛА и основной облачной платформы) для обеспечения умеренно сложного сетевого сервиса. Однако в этом нет необходимости, и протокол может быть продолжен для поддержки сценариев, в которых участвует только облачная платформа БПЛА.

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

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

Materials

Name	Company	Catalog Number	Comments
AR. Drone 2.0 - Elite edition	Parrot		UAV used in the experiment to transport the RPis and thus, provide mobility to the compute units of the UAV cloud platform.
Bebop 2	Parrot		UAV used in the experiment to transport the RPis and thus, provide mobility to the compute units of the UAV cloud platform.
Commercial Intel Core Mini-ITX Computer	Logic Suppy		Computer server which hosts the OpenStack controller node (being executed as a VM) of the experiment's UAV cloud platform. In addition, another unit of this equipment (along with the RPis) conforms the computational resources of the UAV cloud platform.
Linux Containers (LXC)	Canonical Ltd.		(Software) Virtualization technology that enables the supply of the Virtual Network Functions detailed in the experiment. Source-code available online: https://linuxcontainers.org
Lithium Battery Pack Expansion Board. Model KY68C-UK	Kuman		Battery-power supply HAT (Hardware Attached on Top) for the computation units of the UAV cloud platform (i.e., the Raspberry Pis). In addition, this equipment encompasses the case used to attach the compute units (i.e., the Raspberry PIs or RPis) to the UAVs.
MacBook Pro	Apple		Commodity laptop utilized during the experiment to obtain and gather the results as described in the manuscript.
ns-3 Network Simulator	nsnam		(Software) A discrete-event simulator network simulator which provides the underlying communication substrate to the emulation station explained in the "Protocol" section (more specifically in the step "2. Validate the functionality of the softwarization units via Emulation"). Source-code available online: https://www.nsnam.org
Open Source MANO (OSM) - Release FOUR	ETSI OSM - Open source community		(Software) Management and Orchestration (MANO) software stack of the NFV system configured in the experiment. Source-code available online: https://osm.etsi.org/wikipub/index.php/OSM_Release_FOUR
OpenStack - Release Ocata	OpenStack - Open source community		(Software) Open source software used for setting up both the UAV cloud platform and the core cloud within the experiment. Source-code available online: https://docs.openstack.org/ocata/install-guide-ubuntu
Ping	Open source tool		(Software) An open source test tool, which verifies the connectivity between two devices connected through a communications network. In addition, this tool allows to assess the network performance since it calculates the Round Trip Time (i.e., the time taken to send and received a data packet from the network). Source-code available online: https://packages.debian.org/es/sid/iputils-ping
Power Edge R430	Dell		High-profile computer server which provides the computational capacity within the core cloud platform presented in the experiment.
Power Edge R630	Dell		Equipment used for hosting the virtual machine (VM) on charge of executing the MANO stack. In addition, the OpenStack controller node is also executed as a VM in this device. Note that the use of this device is not strictly needed. The operations carried out by this device could be done by a lower performance equipment due to the non-high resource specifications of the before mentioned VMs.
Prestige 2000W	ZyXEL		Voice over IP Wi-FI phone, compatible with the IEEE 802.11b wireless communications standard. This device is utilized to carry out the VoIP call through the network service hosted by platform described for the execution of the experiment.
Raspberry PI. Model 3b	Raspberry Pi Foundation		Selected model of Single Board Computer (SBC) used for providing the computational capacity to the experiment's UAV cloud platform.
SIPp	Open source tool		(Software) An open source test tool, which generates SIP protocol traffic. This tool allows to verify the proper support of the signalling traffic required in an IP telephony service such as the one deployed in the experiment. Source-code available online: http://sipp.sourceforge.net
Tcpdump	Open source tool		(Software) An open source tool that enables the capture and analysis of the network traffic. Source-code available online: https://www.tcpdump.org
Trafic	Open source tool		(Software) An open souce flow scheduler that is used for validating the capacity of the network service deployed to process data traffic generated during an IP telephony call. Source-code available online at: https://github.com/5GinFIRE/trafic