Методическая статья

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

DOI:

10.3791/60425

⸱

26 ноября 2019 г.

 ,  ,  ,  ,  , 
1Department of Telematic Engineering, Universidad Carlos III de Madrid, 2IMDEA Networks Institute

* These authors contributed equally

В этой статье

Краткое содержание

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

Аннотация

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

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

Введение

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

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

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

В частности, интеграция технологий 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 для устройств.

Протокол

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

  1. Установите стек программного обеспечения управления и оркестровки (MANO), предоставленный проектом MANO открытого исходного кода (OSM). В частности, в этом эксперименте используется OSM Release FOUR20, который может быть выполнен на одном серверном компьютере или в виртуальной машине (VM), выполняющей требования, указанные сообществом OSM: Ubuntu 16.04 в качестве операционной системы (64-битное изображение варианта), два центральных процессорных блока (CPUs), 8 ГБ случайной памяти доступа (RAM), 40 ГБ накопительного диска и единый сетевой интерфейс с доступом в Интернет. Процедура установки OSM Release FOUR вместе с его техническими деталями доступна в онлайн-документации, предоставленной сообществом OSM21.
  2. Настройка платформы облачных вычислений, обеспечивающая функции виртуального менеджера инфраструктуры (VIM), совместимого с OSM Release FOUR. Для этого эксперимента используется релиз OpenStack Ocata22, работающий в VM с Ubuntu 16.04 в качестве операционной системы, четырех процессоров, 16 ГБ оперативной памяти и 200 ГБ накопителя. В эксперименте VIM управляет инфраструктурой NFV (NFVI), интегрированной двумя высокопрофильными серверными компьютерами, каждый из которых имеет Ubuntu 16.04 в качестве операционной системы, восемь процессоров, 128 ГБ оперативной памяти и 4 ТБ накопительных диска. Вся информация о том, как настроить платформу облачных вычислений, включена в руководство по установке, включенное в документацию OpenStack23. Эта облачная платформа называется основной облачной платформой.
  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. В качестве альтернативы голосовой вызов может быть выполнен с помощью приложений софтфона, таких как Linphone24 или Jitsi25.
  7. В качестве экспериментального требования убедитесь в наличии: a) связи слоя-3 между стеком программного обеспечения OSM и каждым из ВИМ-си, с тем чтобы можно было организовать организованное развертывание сетевой службы, разработанной для этого эксперимента, b) между OSM и VNF на каждой облачной платформе для поддержки процедур конфигурации VNF, и c) связь слоя-3 между VNFs, работающая на каждом VIM, чтобы обеспечить надлежащее функционирование сетевого сервиса.
  8. Все содержимое, необходимое для проведения эксперимента, содержится в публичном хранилище экспериментов http://vm-images.netcom.it.uc3m.es/JoVE/.

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

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

  1. Загрузите эмуляционную платформу из репозитория эксперимента. Платформа доступна в виде виртуальной машины под названием "uav-nfv-jove-experiment.qcow", совместимая с технологией виртуализации KVM28. Эта машина содержит заранее созданный шаблон, который эмулирует сетевой сервис и сценарий мульти-БПЛА, представленный на рисунке 1, и пользователя с привилегиями администратора, способными выполнять этот шаблон.
    ПРИМЕЧАНИЕ: По умолчанию, следующие шаги автоматически выполняются при запуска художня платформы эмуляции: а) виртуальная среда настроена таким образом, чтобы система эмуляции сети (т.е. сетевые интерфейсы, Мосты Linux29); 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" инструмент30. "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 Mate32 16.04.6 в качестве операционной системы, учитывая, что пакеты установки OpenStack включены в этот дистрибутив Linux.
    2. Установите и назначайте необходимые пакеты, указанные в документации OpenStack33, чтобы позволить 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 можно найти в информационной модели OSM34.
  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, для дальнейшей обработки. Смотрите результаты представительства.

Результаты

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

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

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

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

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

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

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

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

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

Обсуждение

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

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

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

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

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

Раскрытие информации

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Авторам нечего раскрывать.

Благодарности

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Эта работа была частично поддержана европейским проектом H2020 5GRANGE (грантовое соглашение 777137) и проектом 5GCIty (TEC2016-76795-C6-3-R), финансируемым испанским министерством экономики и конкурентоспособности. Работа Луиса Ф. Гонсалеса была частично поддержана европейским проектом H2020 5GinFIRE (грантовое соглашение 732497).

Материалы

Список материалов, использованных в этой статье
ИмяКомпанияКаталожный номерКомментарии
AR. Drone 2.0 - Elite editionParrotUAV, используемый в эксперименте для транспортировки БПЛА и, таким образом, обеспечения мобильности вычислительных блоков облачной платформы БПЛА.
БПЛА Bebop 2Parrotиспользовался в эксперименте для транспортировки БПЛА и, таким образом, обеспечения мобильности вычислительных блоков облачной платформы БПЛА.
Intel Core Mini-ITX ComputerLogic Suppy, на котором размещен узел контроллера OpenStack (выполняемый как виртуальная машина) облачной платформы БПЛА эксперимента. Кроме того, еще одна единица этого оборудования (наряду с РПи) соответствует вычислительным ресурсам облачной платформы БПЛА.
Контейнеры Linux (LXC)Canonical Ltd.(Программное обеспечение) Технология виртуализации, обеспечивающая предоставление функций виртуальной сети, описанных в эксперименте. Исходный код доступен в Интернете: плата
расширения https://linuxcontainers.org литиевого аккумуляторного блока. Модель KY68C-UKKumanBattery-источник питания HAT (Hardware Attached on Top) для вычислительных блоков облачной платформы БПЛА (т.е. Raspberry Pi). Кроме того, это оборудование включает в себя корпус, используемый для подключения вычислительных блоков (т.е. Raspberry PI или RPi) к БПЛА.
MacBook ProAppleCommodity, использованный во время эксперимента для получения и сбора результатов, описанных в рукописи.
ns-3 Network Simulatornsnam(Software) Дискретно-событийный симулятор сети, который предоставляет базовую коммуникационную подложку для эмуляционной станции, описанной в разделе «Протокол» (более конкретно в шаге «2. Проверка функциональности блоков softwarization с помощью эмуляции»). Исходный код доступен в Интернете: https://www.nsnam.org
Open Source MANO (OSM) - Release FOURETSI OSM - Программный стек с открытым исходным кодом дляуправления и оркестровки (MANO) системы NFV, настроенной в эксперименте. Исходный код доступен в Интернете: https://osm.etsi.org/wikipub/index.php/OSM_Release_FOUR
OpenStack - Release OcataOpenStack - Open source community(Software) Программное обеспечение с открытым исходным кодом, используемое для настройки как облачной платформы БПЛА, так и основного облака в рамках эксперимента. Исходный код доступен в Интернете: https://docs.openstack.org/ocata/install-guide-ubuntu
PingOpen source tool(Software) Инструмент тестирования с открытым исходным кодом, который проверяет связь между двумя устройствами, подключенными через коммуникационную сеть. Кроме того, этот инструмент позволяет оценить производительность сети, поскольку он рассчитывает время кругового пути (т.е. время, затраченное на отправку и получение пакета данных из сети). Исходный код доступен в Интернете: https://packages.debian.org/es/sid/iputils-ping
Power Edge R430DellВысокопрофильный компьютерный сервер, который обеспечивает вычислительные мощности в рамках основной облачной платформы, представленной в эксперименте.
Power Edge R630Оборудование Dellиспользуемое для размещения виртуальной машины (VM) на ответственном уровне за выполнение стека MANO. Кроме того, узел контроллера OpenStack также выполняется в качестве виртуальной машины на этом устройстве. Обратите внимание, что использование этого устройства не является строго необходимым. Операции, выполняемые этим устройством, могут выполняться оборудованием с меньшей производительностью из-за невысоких ресурсных характеристик вышеупомянутых виртуальных машин.
Телефон Prestige 2000WZyXELVoice over IP Wi-Fi, совместимый со стандартом беспроводной связи IEEE 802.11b. Это устройство используется для выполнения вызова VoIP через сетевую службу, размещенную на платформе, описанной для выполнения эксперимента.
Малина ПИ. Модель 3bRaspberry Pi FoundationВыбранная модель одноплатного компьютера (SBC), используемого для предоставления вычислительной мощности облачной платформе БПЛА эксперимента.
SIPpOpen source tool(Software) Инструмент тестирования с открытым исходным кодом, который генерирует трафик протокола SIP. Этот инструмент позволяет проверить надлежащую поддержку сигнального трафика, необходимого в сервисе IP-телефонии, подобном тому, который был развернут в эксперименте. Исходный код доступен в Интернете: http://sipp.sourceforge.net
TcpdumpOpen source tool(Software) Инструмент с открытым исходным кодом, который позволяет захватывать и анализировать сетевой трафик. Исходный код доступен в Интернете: https://www.tcpdump.org
Traficоткрытым исходным кодом(программное обеспечение) Планировщик потоков с открытым исходным кодом, который используется для проверки пропускной способности сетевого сервиса, развернутого для обработки трафика данных, генерируемого во время вызова IP-телефонии. Исходный код доступен в сети Интернет по адресу: https://github.com/5GinFIRE/trafic
Коммерческий компьютерный сервер Ноутбук , Инструмент с

Ссылки

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,
  1. Sanchez-Aguero, V., Nogales, B., Valera, F., Vidal, I. Investigating the deployability of VoIP services over wireless interconnected Micro Aerial Vehicles. Internet Technology Letters. 1 (5), 40(2018).
  2. Maxim, V., Zidek, K. Design of high-performance multimedia control system for UAV/UGV based on SoC/FPGA Core. Procedia Engineering. 48, 402-408 (2012).
  3. Vidal, I., et al. Enabling Multi-Mission Interoperable UAS Using Data-Centric Communications. Sensors. 18 (10), 3421(2018).
  4. Vidal, I., Valera, F., Díaz, M. A., Bagnulo, M. Design and practical deployment of a network-centric remotely piloted aircraft system. IEEE Communications Magazine. 52 (10), 22-29 (2014).
  5. Jin, Y., Minai, A. A., Polycarpou, M. M. Cooperative real-time search and task allocation in UAV teams. 42nd IEEE International Conference on Decision and Control. 1, IEEE. IEEE Cat. No. 03CH37475 7-12 (2003).
  6. Maza, I., Ollero, A. Multiple UAV cooperative searching operation using polygon area decomposition and efficient coverage algorithms. Distributed Autonomous Robotic Systems. 6, Springer. Tokyo. 221-230 (2007).
  7. Quaritsch, M., et al. Collaborative microdrones: applications and research challenges. Proceedings of the 2nd International Conference on Autonomic Computing and Communication Systems. , ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering. 38(2008).
  8. Waharte, S., Trigoni, N., Julier, S. Coordinated search with a swarm of UAVs. 2009 6th IEEE Annual Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks Workshops. , IEEE. 1-3 (2009).
  9. De Freitas, E. P., et al. UAV relay network to support WSN connectivity. International Congress on Ultra-Modern Telecommunications and Control Systems. , IEEE. 309-314 (2010).
  10. European Telecommunications Standards Institute. Network Functions Virtualisation (NFV); Architectural Framework; Research Report ETSI GS NFV 002 V1.2.1. European Telecommunications Standards Institute. (ETSI). , (2014).
  11. An Open Source NFV Management and Orchestration (MANO) software stack aligned with ETSI NFV. ETSI OSM. , Available from: https://osm.etsi.org/ (2019).
  12. Nogales, B., et al. Design and Deployment of an Open Management and Orchestration Platform for Multi-Site NFV Experimentation. IEEE Communications Magazine. 57 (1), 20-27 (2019).
  13. Omnes, N., Bouillon, M., Fromentoux, G., Le Grand, O. A programmable and virtualized network & IT infrastructure for the internet of things: How can NFV & SDN help for facing the upcoming challenges. 18th International Conference on Intelligence in Next Generation Networks. , IEEE. 64-69 (2015).
  14. Rametta, C., Schembra, G. Designing a softwarized network deployed on a fleet of drones for rural zone monitoring. Future Internet. 9 (1), 8(2017).
  15. Garg, S., Singh, A., Batra, S., Kumar, N., Yang, L. T. UAV-empowered edge computing environment for cyber-threat detection in smart vehicles. IEEE Network. 32 (3), 42-51 (2018).
  16. Mahmoud, S., Jawhar, I., Mohamed, N., Wu, J. UAV and WSN softwarization and collaboration using cloud computing. 3rd Smart Cloud Networks & Systems (SCNS). , IEEE. 1-8 (2016).
  17. González Blázquez, L. F., et al. NFV orchestration on intermittently available SUAV platforms: challenges and hurdles. 1th Mission-Oriented Wireless Sensor, UAV and Robot Networking (MISARN). , IEEE. (2019).
  18. Nogales, B., Sanchez-Aguero, V., Vidal, I., Valera, F., Garcia-Reinoso, J. A NFV system to support configurable and automated multi-UAV service deployments. Proceedings of the 4th ACM Workshop on Micro Aerial Vehicle Networks, Systems, and Applications. , ACM. 39-44 (2018).
  19. Nogales, B., Sanchez-Aguero, V., Vidal, I., Valera, F. Adaptable and automated small UAV deployments via virtualization. Sensors. 18 (12), 4116(2018).
  20. Hoban, A., et al. An ETSI OSM Community White Paper, OSM Release FOUR: A Technical Overview. European Telecommunications Standards Institute. (ETSI). , Whitepaper (2018).
  21. Quick start installation and use guide. Open Source MANO Release FOUR. , Available from: https://osm.etsi.org/wikipub/index.php/OSM_Release_FOUR (2019).
  22. Open Source Software for Creating Private and Public Clouds. OpenStack. , Available from: https://docs.openstack.org/ocata (2019).
  23. OpenStack Installation Tutorial for Ubuntu. OpenStack. , Available from: https://docs.openstack.org/ocata/install-guide-ubuntu/ (2019).
  24. Linphone. An Open Source VoIP SIP Softphone for voice/video calls and instant messaging. Linphone. , Available from: https://www.linphone.org (2019).
  25. An Open Source Project to easily build and deploy secure video-conferencing solutions. Jitsi. , Available from: https://jitsi.org (2019).
  26. Infrastructure for container projects. Linux Containers (LXC). , Available from: https://linuxcontainers.org (2019).
  27. A Discrete-Event Network Simulator for Internet Systems. Ns-3. , Available from: https://www.nsnam.org/ (2019).
  28. Kernel-based Virtual Machine (KVM). A virtualization solution for Linux. Linux. , Available from: https://www.linux-kvm.org (2019).
  29. Bridging & firewalling. Linux Foundation. , Available from: https://wiki.linuxfoundation.org/networking/bridge (2019).
  30. An Open Source test tool and/or traffic generator for the SIP protocol. SIPp. , Available from: http://sipp.sourceforge.net/ (2019).
  31. Trafic. An open source flow scheduler. , Available from: https://github.com/5GinFIRE/trafic (2019).
  32. Ubuntu Mate for the Raspberry Pi. , Available from: https://ubuntu-mate.org/raspberry-pi/ (2019).
  33. Enabling LXC (Linux Containers) as virtualization technology. OpenStack. , Available from: https://docs.openstack.org/ocata/config-reference/compute/hypervisor-lxc.html (2019).
  34. Open Source MANO Information Model. , Available from: https://osm.etsi.org/wikipub/index.php/OSM_Information_Model (2019).
  35. ITU-T. ITU-T Recommendation G.114. General Recommendations on the transmission quality for an entire international telephone connection; One-way transmission time. International Telecommunication Union - Telecommunication Standardization Sector. , (2003).

Перепечатки и разрешения

Запросить разрешение на повторное использование текста или иллюстраций этой статьи JoVE

Запросить разрешение

Теги

IPVNFOSMVIMIP VoIP

Похожие статьи