Интеграция инфраструктур экспериментов 5G в многосайтовую экосистему NFV

Summary

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

Abstract

Виртуализация сетевых функций (NFV) считается одним из ключевых факторов для^5-го поколения мобильных сетей, или 5G. Такая парадигма позволяет снизить зависимость от специализированного оборудования для развертывания телекоммуникационных и вертикальных сервисов. Для этого он опирается на методы виртуализации для мягкой войны сетевых функций, упрощая их разработку и сокращая время и затраты на развертывание. В этом контексте Universidad Carlos III de Madrid, Telefónica и IMDEA Networks Institute разработали экосистему NFV внутри 5TONIC, открытого сетевого инновационного центра, ориентированного на технологии 5G, что позволяет создавать сложные, близкие к реальности сценарии экспериментов в распределенном наборе инфраструктур NFV, которые могут быть доступны заинтересованным сторонам в разных географических точках. В этой статье представлен протокол, который был определен для включения новых удаленных сайтов NFV в многосайтовую экосистему NFV на основе 5TONIC, описывающий требования как к существующей, так и к вновь включенной инфраструктурам, их подключение через архитектуру оверлейной сети и шаги, необходимые для включения новых сайтов. Примером протокола является включение внешнего сайта в экосистему 5TONIC NFV. После этого в протоколе подробно описываются шаги проверки, необходимые для успешной интеграции сайта. К ним относится развертывание многосайтовой вертикальной службы с использованием удаленной инфраструктуры NFV с малыми беспилотными летательными аппаратами (БПЛА). Это служит для демонстрации потенциала протокола для реализации распределенных сценариев экспериментирования.

Introduction

Внедрение пятого поколения мобильных сетей (5G) подразумевает революцию в телекоммуникационной отрасли с начала десятилетия, требуя от телекоммуникационных операторов учитывать гораздо более требовательные спецификации новых сетевых услуг и приложений, разработанных под зонтиком 5G^1,2 . Эти новые спецификации включают, но не ограничиваются ими, увеличение скорости передачи данных, улучшение задержки беспроводной передачи и снижение эксплуатационных расходов. Среди технологий, которые составляют основу улучшений для этого нового поколения, виртуализация сетевых функций³ (NFV) стала одним из его ключевых факторов. NFV предоставляет возможность программного управления сетевыми функциями, традиционно ретранслируя на специализированном оборудовании, используя вместо этого физическое оборудование общего назначения, такое как серверные компьютеры в центре обработки данных. С помощью этой новой парадигмы телекоммуникационные операторы и вертикальные отрасли могут развертывать сетевые функции и услуги в виде набора программных компонентов и экономить затраты как на развертывание, так и на обслуживание услуг, а также способствовать гораздо более высокой эластичности сетевой инфраструктуры. Такой подход облегчает или устраняет необходимость использования выделенных (и, как правило, более сложных и менее многоразовых) устройств для большинства сетевых и вертикальных функций и поддерживает гораздо более высокую и плотную степень автоматизации операций, что снижает затраты на развертывание и обслуживание.

Принимая во внимание все преимущества, которые может предоставить среда NFV, естественно, что большое количество соответствующих заинтересованных сторон из телекоммуникационного сектора все чаще участвуют в тестировании новых идей услуг в средах NFV. В этом контексте Telefónica и IMDEA Networks Institute создали 5TONIC^4,открытую исследовательскую и инновационную лабораторию, ориентированную на технологии 5G. Эта лаборатория, базирующаяся в Мадриде (Испания), имеет широкий спектр технологий, доступных для исследователей и партнеров, чтобы стимулировать разработку и проверку услуг 5G. В частности, эта лаборатория имеет экспериментальную платформу NFV, где разработчики могут развертывать и тестировать свои новые приложения и сервисы на основе NFV на ETSI-совместимой экосистеме NFV^5. Таким образом, экспериментальные выводы о выборе конструкции и технологических предложениях могут быть получены в реалистичной гораздо более гибкой среде, чем производственные сети. Эта платформа была разработана для поддержки экспериментальных мероприятий на нескольких внешних сайтах, которые могут быть гибко связаны с 5TONIC с использованием четко определенного протокола.

Техническое решение, принятое для экосистемы 5TONIC NFV, предусматривает использование одного оркестратора NFV, реализованного с использованием программного обеспечения Open Source MANO (OSM) с открытым исходным кодом (OSM)^6. Это элемент, отвечающий за управление и координацию жизненного цикла сетевых служб (NS). Эти сервисы могут быть построены как композиция виртуализированных сетевых/вертикальных функций (VNF), которые могут быть развернуты на любом из сайтов, интегрированных на платформе NFV. Проектирование экосистемы 5TONIC NFV было выполнено в контексте проекта H2020 5GINFIRE^7,8,где платформа использовалась для поддержки выполнения более 25 экспериментов, отобранных в ходе конкурентного процесса открытого вызова, в восьми вертикальных экспериментальных инфраструктурах, расположенных в Европе, и одной в Бразилии, последняя из которых соединена через трансокеаническую связь. Кроме того, платформа была использована для создания распределенного испытательного стенда NFV в национальном масштабе в Испании, поддерживая экспериментальную деятельность в рамках испанского проекта 5GCity^9,10. Совсем недавно в платформу была интегрирована дополнительная бразильская площадка для поддержки совместных демонстрационных мероприятий в контексте научно-исследовательского и инновационного сотрудничества, установленного между Бразилией и Европой (т.е. проект 5GRANGE^11,12). И последнее, но не менее важное: инфраструктура была использована для поддержки сторонних экспериментов в рамках проекта 5G-VINNI^13,14. Географическое распределение платформы NFV можно увидеть на рисунке 1.

Заинтересованные организации, размещающие собственную инфраструктуру NFV, могут гибко подключаться к экосистеме 5TONIC NFV при условии одобрения Руководящим советом 5TONIC, становиться поставщиками испытательных стендов в рамках распределенной экосистемы и участвовать в совместных экспериментах и демонстрационных мероприятиях. Для этого они должны иметь VIM (Virtual Infrastructure Manager), совместимый со стеком программного обеспечения OSM. Оркестратор 5TONIC NFV способен взаимодействовать с VIC на сайтах, участвующих в развертывании данной службы, координируя распределение и настройку вычислительных ресурсов, ресурсов хранения и сетевых ресурсов, необходимых для создания экземпляров и объединения VNF, составляющих сетевую службу, и контролируя ее жизненный цикл от ее адаптации до окончательного вывода из эксплуатации.

Чтобы управлять обменом контролем и трафиком данных во всех взаимосвязанных сайтах, экосистема 5TONIC NFV использует архитектуру оверлейной сети на основе виртуальных частных сетей (VPN). Этот подход обеспечивает безопасный доступ на основе PKI к внешним сайтам, интегрированным в экосистему 5TONIC, что позволяет обмениваться управляющей информацией NFV между программным стеком OSM и различными ВИР-моделями, распределенными по испытательным стендам, а также обмениваться информацией, необходимой для управления и настройки всех VNF. Кроме того, эта оверлейная сеть поддерживает распространение трафика данных между VNF, которые развернуты на разных сайтах.

В этом контексте в этом документе подробно описывается протокол, предназначенный для включения внешнего сайта в экосистему NFV. Протокол предполагает, что экосистема управляется одним оркестратором NFV, установленным на центральном сайте, а внешние сайты имеют решение VIM, совместимое со стеком программного обеспечения оркестратора. Предлагаемый протокол позволяет увеличить портфель ресурсов экспериментальной экосистемы с гибким включением сайтов NFV и вертикальных инфраструктур. Это позволяет создать распределенную платформу MANO, способную тестировать и проверять новые сетевые и вертикальные сервисы на нескольких сайтах под управлением одного оркестратора NFV. Чтобы проиллюстрировать внутреннюю работу протокола, процесс будет проиллюстрирован путем добавления внешнего сайта NFV к текущей экосистеме 5TONIC NFV, описания необходимых компонентов на внешнем сайте и 5TONIC, а также всех шагов, которые необходимо предпринять в процессе интеграции. На рисунке 2 представлен обзор цели интеграции с новым испытательным стендом на основе NFV, подключенным к платформе 5TONIC, откуда сетевые службы могут быть развернуты с помощью VPN-соединений между центральным сайтом и остальными внешними инфраструктурами.

Кроме того, чтобы продемонстрировать эффективность протокола, будет показано развертывание простой вертикальной службы с использованием экосистемы 5TONIC и внешней площадки с малыми беспилотными летательными аппаратами (БПЛА), способными к NFV. Дизайн вертикальной службы был вдохновлен экспериментом, представленным в Vidal et al.^9,который был упрощен для иллюстрации в этой статье. На рисунке 3 показана услуга, которая направлена на оказание помощи в области интеллектуального земледелия в отдаленном районе. Сервис рассматривает поставщика услуг умного сельского хозяйства, который использует БПЛА для сбора и распространения данных, полученных метеорологическими датчиками, разбросанными по сельскохозяйственному полю. Для простоты эксперимент, представленный в статье, рассматривает один SUAV и датчик, способный обеспечить измерения температуры, влажности и давления. В эксперименте на внешнем сайте NFV размещается точка доступа Wi-Fi, развернутая как VNF через SUAV. Этот VNF обеспечивает сетевой доступ к датчику, перенаправляя чувствительные данные в функцию шлюза. Последний развертывается в качестве VNF на наземном оборудовании (компьютер mini-ITX). Распространение данных от датчика к функции шлюза осуществляется в соответствии с подходом Publish/Subscribe, основанным на протоколе MQTT (Message Queuing Telemetry Transport)^15. Функция шлюза обрабатывает, а затем распространяет данные на сервер Интернета вещей (IoT), который доступен в качестве VNF на центральном сайте экосистемы NFV на основе платформы с открытым исходным кодом Mainflux^16. Наконец, сценарий предполагает удаленную область, где подключение к Интернету обеспечивается сотовой сетью доступа, отличной от 3GPP. Следовательно, услуга включает в себя два дополнительных VNF: 1) маршрутизатор доступа VNF, который реализует стек протоколов пользовательской плоскости пользовательского оборудования 3GPP, подключенного к сети доступа без 3GPP^17; и 2) базовая реализация базовой сети 5G, поддерживающая пересылку информации между маршрутизатором доступа и VNF сервера IoT. С этой целью ядро 5G VNF обеспечивает упрощенную реализацию плоскости пользователя не-3GPP взаимодействующей функции и функции плоскости пользователя, как определено 3GPP^17.

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

Protocol

1. Предоставление центрального участка экосистемы NFV (предварительные реквизиты эксперимента)

1. Выделите пространство IP-адреса, которое будет использоваться центральным сайтом. Для целей этого протокола будет использоваться частное адресное пространство 10.4.0.0/16.
2. Установите стек программного обеспечения управления и оркестровки (MANO) на центральном сайте. В частности, в эксперименте, проводимом на протяжении всего этого протокола, используется Open Source MANO (OSM) Release SEVEN^18,который требует следующих ресурсов: Ubuntu 18.04 в качестве операционной системы, 2 центральных процессорных блока (CPU), 8 ГБ оперативной памяти (RAM), 40 ГБ жесткого диска-диска и, по крайней мере, одного сетевого интерфейса с доступом в Интернет. Для установки следуйте инструкциям, доступным в документации OSM Release SEVEN¹⁸.
3. Настройте диспетчер виртуальной инфраструктуры (VIM), совместимый с OSM, на центральном сайте. В частности, в эксперименте Используется OpenStack релиз Ocata^20,работающий на виртуальной машине (VM) с Ubuntu 16.04, 4 процессорами, 16 ГБ оперативной памяти и 200 ГБ жесткого диска. Инфраструктура NFV (NFVI), обрабатываемая этим VIM, состоит из трех серверных компьютеров, каждый с Ubuntu 16.04, 8 процессорами, 32 ГБ оперативной памяти и 2 ТБ хранилища. Для установки следуйте документации ocata выпуска²¹.
   1. Разверните виртуальную сеть в облачной платформе OpenStack, используя диапазон IP-адресов из адресного пространства, выделенного на шаге 1.1. Эта сеть, далее именуемая сетью управления, будет использоваться для поддержки обмена информацией об оркестрации NFV между OSM и виртуальными сетевыми функциями (VNF), созданными на центральном сайте.
   2. Настройте виртуальную сеть (далее именуемую сетью передачи данных) для поддержки межсайтового обмена данными между VNF центрального сайта и другими VNF, выполняемыми на внешних сайтах. Для этого используйте диапазон IP-адресов из адресного пространства шага 1.1.
      ПРИМЕЧАНИЕ: Реализация сетей, упомянутых в шагах 1.3.1 и 1.3.2, была выполнена с использованием сетей провайдеров OpenStack. Сети провайдеров должны быть подключены к физической сетевой инфраструктуре центрального сайта, чтобы гарантировать соответствующую работу.
4. Подключите как виртуальные частные сети (т.е. сети управления и передачи данных), так и машины VIM и OSM к оборудованию, обеспечивающему функции пограничной маршрутизации. Этот маршрутизатор будет служить точкой входа в центральный сайт экосистемы NFV.
5. Сделайте доступным общедоступный репозиторий экспериментов, чтобы предоставить все содержимое, необходимое для проведения эксперимента. В частности, этот протокол использует публичный репозиторий на²².

2. Настройка службы виртуальной частной сети

1. Выделите пространство IP-адресов для поддержки надлежащей работы экосистемы с несколькими сайтами, чтобы можно было эффективно устанавливать сетевую связь между несколькими сайтами.
   ПРИМЕЧАНИЕ: Обеспечение эффективной сетевой связи между несколькими сайтами требует тщательного проектирования пространства IP-адресов, которое будет использоваться экосистемой NFV, а также внешними сайтами, которым необходимо подключиться к нему. В частности, адресное пространство, выделенное для межсайтовой связи, не должно сталкиваться с адресным пространством, уже используемым на любом другом сайте для других целей.
   1. Выделите пространство IP-адресов для использования внешними сайтами. Адреса в этом блоке будут назначены сущностям NFV (например, VIM) и VNF внешнего сайта. В качестве примера этого протокола будет использоваться частное адресное пространство 10.154.0.0/16.
   2. Выделите пространство IP-адресов виртуальным ссылкам между внешними сайтами и экосистемой NFV. Эти виртуальные ссылки будут поддерживаться VPN-сервисом. Чтобы проиллюстрировать этот протокол, для этих виртуальных каналов будет использоваться диапазон адресов 10.154.254.0/24.
2. Настройте оборудование для предоставления службы виртуальной частной сети (VPN) (т. е. VPN-сервера). В частности, в эксперименте используется серверный компьютер с Ubuntu 16.04 (64-битный вариант образа), шестью независимыми процессорами, 16 ГБ ОЗУ, 1 ТБ диска хранения и двумя сетевыми интерфейсами.
   1. Настройте один из сетевых интерфейсов VPN-сервера, чтобы разрешить прием запросов на подключение от внешних сайтов через Интернет. Для этого необходимо использовать интерфейс сервера, настроенный с публичным IP-адресом.
   2. Настройте связь между VPN-сервером и пограничным маршрутизатором центрального сайта. В эксперименте по этой ссылке был выделен диапазон адресов 10.4.255.0/24. Настройте соответствующие сетевые маршруты на VPN-сервере, чтобы экосистема NFV стала доступной с внешних сайтов, подключенных к службе VPN.
3. Установите программное обеспечение VPN с открытым исходным кодом, предоставляемое проектом OpenVPN^23, на VPN-сервер. В частности, в этом эксперименте используется OpenVPN версии 2.3.10, а его развертывание осуществлялось с помощью bash-скрипта "openvpn-install.sh", доступного на http://github.com/Nyr/openvpn-install (другие варианты установки описаны в документации OpenVPN ^24). Сценарий bash представляет альтернативные параметры, которые приведут к настройке службы VPN.
   1. Выберите IP-адрес для прослушивания запросов VPN-подключения (т. е. общедоступный IP-адрес).
   2. Решите, какой протокол (UDP или TCP) следует использовать для управления связью через VPN. В этом случае эксперимент использует UDP, который является рекомендуемым протоколом.
   3. Укажите порт, который будет содержать дупл (вместе с общедоступным IP-адресом), который будет использоваться для получения запросов на подключение к службе. По умолчанию назначено значение 1194.
   4. Выберите один из DNS-серверов списка, запрашиваемого помощником, который будет обрабатывать запросы разрешения имен, выполняемые клиентами СЛУЖБЫ VPN.
   5. Нажмите любую клавишу, чтобы включить автоматическое инициирование процесса установки VPN-сервиса.
4. Отредактируйте конфигурационный файл "server.conf", расположенный в каталоге "/etc/openvpn/server/" и включите директиву "client-to-client" с целью расширения базовой настройки, предусмотренной в шаге 2.3. Таким образом, разные клиенты, подключенные к VPN-сервису, смогут связаться друг с другом.
5. Включите индивидуальную конфигурацию клиента в настройках VPN, чтобы иметь возможность независимо управлять назначениями маршрутизации для каждого клиента.
   1. Добавьте директиву "client-config-dir ccd", отредактировав тот же конфигурационный файл, что и на шаге 2.4.
   2. Создайте каталог "ccd" с помощью команды "mkdir /etc/openvpn/ccd/". Этот каталог будет служить в следующем разделе протокола для размещения файлов, содержащих директивы маршрутизации, связанные с клиентами, предназначенными для интеграции в платформу.
6. Настройте правила брандмауэра, необходимые для разрешения подключений к службе, защищая VPN-сервер от вредоносных атак. С этой целью в этом эксперименте используется iptables^25,которая является утилитой командной строки, разработанной для настройки брандмауэра ядра Linux.
   1. Сначала заблокируйте входящий трафик на VPN-сервер с помощью команды "iptables -P INPUT DROP".
   2. Разрешить прием запросов VPN-подключения с помощью команд "iptables -A INPUT -i -m state --state NEW -p udp --dport 1194 -j ACCEPT" ( - имя интерфейса VPN-сервера с общедоступным IP-адресом) и "iptables -A INPUT -i tun+ -j ACCEPT".
   3. Разрешить пересылку трафика между интерфейсами VPN-сервера (т. е. общедоступным интерфейсом и виртуальным интерфейсом, созданным службой VPN под названием tun0),чтобы позволить VPN-серверу обрабатывать запрос на подключение к службе. Для этого выполните команду "iptables -A FORWARD -i tun+ -o -m state --state RELATED,ESTABLISHED -j ACCEPT && iptables -A FORWARD -i -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT".
   4. Включите VPN-сервер для предоставления возможности преобразования сетевых адресов (NAT) с целью предоставления доступа в Интернет центральному сайту, выполнив: "iptables -t nat -A POSTROUTING -s 10.4.0.0/16 -o -j MASQUERADE && iptables -A OUTPUT -o tun+ -j ACCEPT".

3. Интеграция внешнего сайта NFV

1. Получите соответствующий диапазон IP-адресов для интеграции сайта в экосистему NFV. Этот диапазон адресов будет предоставлен центром сетевых операций экосистемы NFV. Согласно шагу 2.1.1 этого протокола, эксперимент будет использовать диапазон IP-адресов для внешнего сайта в пределах 10.154.0.0/16.
2. Создайте и предоставьте учетные данные безопасности для подключения к экосистеме NFV.
   1. Создайте учетные данные VPN, которые позволят новой инфраструктуре установить безопасное соединение с VPN-сервером. Для этого выполните команду «bash openvpn-install.sh» на VPN-сервере, выберите опцию «1) Добавить нового клиента» в списке запросов и укажите имя, которое будет связано с этими учетными данными, например, uc3m_infrastructure. На этом шаге будет создан файл с учетными данными VPN (в примере с именем «uc3m_infrastructure.ovpn»).
   2. Создайте текстовый файл в каталоге "/etc/openvpn/ccd/" VPN-сервера, включая директивы маршрутизации (как указано в документации OpenVPN ^24),которые должны передаваться VPN-сервером каждый раз при установлении соединения с VPN-сервисом с использованием учетных данных VPN.
      ПРИМЕЧАНИЕ: Имя текстового файла должно совпадать с именем, указанным при создании учетных данных VPN (например, uc3m_infrastructure), чтобы обеспечить индивидуальную конфигурацию для каждого VPN-клиента.
   3. Предоставьте файл учетных данных VPN техническому персоналу внешнего сайта. Это должно быть сделано по безопасному и надежному каналу. В этом эксперименте используется процесс ручного шифрования. Чтобы зашифровать учетные данные VPN, выполните команду «7za a -tzip '-p' -mem=AES256 », установив в качестве требуемого ключа шифрования, <зашифрованный файл>как выбранное имя для зашифрованного файла и в качестве имени файла учетных данных VPN (например, uc3m_infrastructure.ovpn).
   4. Предоставьте зашифрованные учетные данные техническому персоналу нового сайта вместе с ключом, который позволяет выполнять процедуры расшифровки, через безопасный канал связи.
      ПРИМЕЧАНИЕ: В этом эксперименте зашифрованные учетные данные были предоставлены электронной электронной почтой, тогда как ключ расшифровки был отправлен по отдельному каналу, используя службу коротких сообщений (SMS), с автономным согласованием номера телефона.
3. Настройте среду на новом сайте, чтобы установить соединение с экосистемой NFV и позволить удаленному NFVI быть подключенным к стеку OSM центрального сайта.
   1. Установите программное обеспечение VPN, предоставляемое OpenVPN^24, на компьютер, чтобы обеспечить виртуальную связь между внешним сайтом и центральным сайтом экосистемы NFV. Компьютер с программным обеспечением OpenVPN будет служить VPN-клиентом или конечной точкой VPN на внешнем сайте. Виртуальное соединение будет реализовано с помощью защищенного VPN-туннеля между конечной точкой VPN и VPN-сервером. В эксперименте конечная точка VPN работает на серверном компьютере с Ubuntu 18.04, 8 процессорами, 8 ГБ ОЗУ, диском памяти 128 ГБ и интерфейсами GbE (один для подключения к службе VPN через Интернет).
   2. Активируйте IP-пересылку в конечной точке VPN для поддержки возможностей сетевой маршрутизации. С этой целью включите строку "net.ipv4.ip_forward=1" в файл конфигурации системы, расположенный по пути "/etc/sysctl.conf", и загрузите обновленную конфигурацию с помощью команды "sudo sysctl -p".
   3. Расшифруйте файл учетных данных VPN с информацией, полученной на шаге 3.2.4, используя команду «7za e », где <зашифрованный файл> является именем файла зашифрованных учетных данных VPN. Укажите ключ расшифровки при появлении запроса команды.
   4. Загрузите программное обеспечение OpenVPN с расшифрованным файлом учетных данных с помощью команды «sudo openvpn --config » ( — имя файла учетных данных VPN). При этом конечная точка VPN будет аутентифицироваться на VPN-сервере и автоматически получать соответствующие параметры конфигурации VPN и сетевые маршруты. Таким образом, конечная точка VPN будет вести себя как пограничный маршрутизатор с виртуальной связью с центральным сайтом экосистемы NFV.
   5. Проверьте правильность работы конечной точки VPN, используя команду ping для проверки доступности подключения к одному из узлов центрального сайта (например, оборудованию стека OSM).
   6. На новом сайте выберите СОВМЕСТИМЫЙ с OSM VIM, чтобы разрешить операции с платформой MANO. Для этого эксперимента используется выпуск OpenStack Ocata.
      ПРИМЕЧАНИЕ: OSM Release SEVEN поддерживает следующие менеджеры виртуальной инфраструктуры: OpenStack, OpenVIM^26,VMware vCloud Director^27,Amazon Web Service^28,Microsoft Azure²⁹и Eclipse fog05³⁰ (см. документацию ПО OSM¹⁸ для получения конкретных сведений о конфигурации).
   7. Установите выпуск OpenStack Ocata²⁰ (см. подробные процедуры в документации по выпуску^21).
   8. Разверните инфраструктуру NFV на внешнем сайте и подключите ее к VIM. В частности, в этом эксперименте используется инфраструктура NFV, состоящая из трех одноплатных компьютеров (SBC), каждый с вычислительной емкостью 1 ГБ ОЗУ, 4 процессора и 32 ГБ диска хранения; и один компьютер mini-ITX с 8 процессорами, 8 ГБ оперативной памяти и 128 ГБ для хранения.
      ПРИМЕЧАНИЕ: Внешний сайт, приведенный в этом протоколе, основан на инфраструктуре NFV малых беспилотных летательных аппаратов (SUAV), способных поддерживать NFV. Подробности, приведенные для обеспечения такой инфраструктуры, приведены в Nogales et al^31. Шаги 3.3.6-3.3.8 являются необязательными, поскольку инфраструктура NFV может уже существовать на внешней площадке.
   9. Создайте проект OpenStack, чтобы указать набор вычислительных ресурсов внешнего сайта, которые будут интегрированы в экосистему NFV. Для этого необходимо получить доступ к графическому интерфейсу пользователя (GUI), предоставляемому OpenStack, войти в систему с учетными данными администратора, нажать кнопку + Create Project на вкладке Identity -> Projects и создать проект, завершив отображаемую форму с запрошенной информацией.
   10. Создайте допустимого пользователя, который будет управлять проектом, созданным на предыдущем шаге. Для этого перейдите на вкладку Identity -> Users с тем же логином, что и на предыдущем шаге, нажмите + Create User, и заполните необходимые поля отображаемой формы (имя пользователя и пароль), выбрав новый созданный проект в качестве основного проекта и выбрав роль администратора.
   11. Измените правила безопасности, чтобы разрешить разрешения на связь VNF на новом сайте (в частности, включить трафик SSH и ICMP). С этой целью получите доступ к графическому интерфейсу OpenStack с учетными данными пользователя, созданными на предыдущем шаге, следуйте последовательности: Project -> Network -> Security Groups -> + Add Rule, и выберите параметр SSH раскрывающегося списка Правило. Повторите процесс, но выберите опцию Все ICMP, включенную в раскрывающееся меню.
   12. Загрузите изображения пробной службы, предлагаемой сообществом OSM, сетевой службы Ping Pong («Fedora-x86_64-20-20131211.1-sda-ping» и «Fedora-x86_64-20-20131211.1-sda-pong») из общедоступного репозитория экспериментов и загрузите их в VIM внешнего сайта. Для этого следуйте последовательности Project -> Compute -> Images -> + Create Image, и создайте изображения, используя отображаемую форму и выбирая каждое из изображений.
   13. Назначьте два диапазона IP-адресов в адресном пространстве внешнего сайта (выделено на шаге 3.1). Эти диапазоны будут использоваться для поддержки управления VNF внешнего сайта и для обеспечения межсайтовой передачи данных между VNF, соответственно.
   14. Создайте сеть провайдера(control-provider)с помощью VIM. Эта сеть будет поддерживать связь NFV между стеком OSM на центральном сайте и VNF, развернутыми на новом сайте для целей управления. Этот тип связи также позволит стеку OSM настраивать VNF после их развертывания. Чтобы создать сеть провайдера в OpenStack, следуйте последовательности Admin -> System -> Networks -> + Create Network и заполните сведения о новой сети, используя выбранный диапазон IP-адресов на предыдущем шаге.
   15. Создайте вторую сеть провайдера(data-provider)с помощью VIM. Эта сеть будет поддерживать передачу данных между VNF сайта и другими VNF экосистемы NFV. Чтобы создать эту сеть провайдера в OpenStack, следуйте последовательности Admin -> System -> Networks -> + Create Networkи заполните сведения о новой сети, используя назначенный диапазон адресов.
       ПРИМЕЧАНИЕ: Инструкции по созданию виртуальных сетей зависят от программного обеспечения VIM. Ознакомьтесь с соответствующей документацией по программному обеспечению для получения подробной информации.
   16. Поделитесь информацией, связанной с VIM (в частности, именем пользователя/паролем и проектом, созданным на шагах 3.3.9 и 3.3.10), с техническим персоналом центрального сайта, чтобы включить прикрепление VIM к стеку программного обеспечения OSM.
4. Подключите внешнюю инфраструктуру NFV к программному стеку OSM центрального сайта, используя информацию, полученную из шага 3.3.16.
   1. Проверьте связь между стеком OSM центрального сайта и VIM нового сайта с помощью средства проверки связи.
   2. Если предыдущая проверка подключения прошла успешно, подключите внешний VIM к стеку OSM центрального сайта. Для этого используйте следующую команду на компьютере OSM: "osm vim-create --name --user --password --auth_url < URL-адрес проверки подлинности> --tenant --account_type ". В этой команде: <внешняя-VIM-name>имя имя, выбранное для идентификации VIM в стеке OSM, имя имя пользователя, уполномоченного обрабатывать ресурсы внешнего сайта (см. шаг 3.3.10), - это пароль указанного пользователя, < URL-адрес проверки подлинности> - это ссылка на API, предоставляемый VIM для включения запросов из стека OSM , — это имя проекта, определенное на шаге 3.3.9, а — используемое программное обеспечение VIM (в этом эксперименте OpenStack).
5. Проверьте правильность подключения нового VIM к стеку OSM экосистемы NFV.
   1. Выполните команду "ro_id=$(docker ps | grep osm_ro | cut -d ' ' -f 1)" для идентификации идентификатора контейнера, реализующего модуль Resource Orchestrator (RO) в системе OSM. Этот модуль отвечает за взаимодействие с ВИМ с целью координации и распределения необходимых ресурсов при развертывании последующих сетевых сервисов.
   2. Доступ к контейнеру RO с помощью команды "docker exec -it $ro_id bash". Эта команда использует идентификатор, полученный при выполнении предыдущего шага.
   3. Проверьте, включен ли новый VIM в список доступных дата-центров, используя команду "openmano datacenter-list". Новый сайт должен появиться в списке с тем же именем, что и ранее представленный на шаге 3.4.2 с <внешняя-VIM-name>параметр.
   4. Перечислите изображения, загруженные в VIM внешнего сайта, используя команду "openmano vim-image-list --datacenter <внешняя-VIM-name>". Параметр <внешние-VIM-name>параметр указывает имя, выбранное для идентификации VIM в стеке OSM. Если выполнение этой команды выполнено успешно, подключение к внешнему VIM успешно установлено. Убедитесь, что изображения пинг-понга включены в список.
   5. Перечислите сети, доступные на новом сайте, с помощью команды "openmano vim-net-list --datacenter <внешняя-VIM-name>". Убедитесь, что поставщик управления и поставщик данных присутствуют.
6. Выполните предварительную проверку правильной интеграции нового сайта, используя пробный сервис, предлагаемый сообществом OSM (весь контент в этом отношении включен в репозиторий эксперимента). Для этого команды, включенные в следующие шаги, будут выполняться на оборудовании, на котором размещен стек OSM.
   1. Встроенные дескрипторы VNF (VNFD) в стек OSM, выполняющие команду "osm vnfd-create " для каждого из VNF, составляющих пробную службу ( соответствует имени файла пакета VNFD).
   2. Встроенный дескриптор NS (NSD) пробной службы с командой «osm nsd-create », где указывает имя файла пакета NSD (в этом эксперименте ping_pong_ns.tar.gz)».
   3. Запустите создание экземпляра сетевой службы Ping Pong (NS) на внешнем и центральном сайтах, используя команду "osm ns-create --ns_name --nsd_name ping_pong_ns --vim_account <внешняя-VIM-name>--config '{vnf: [{member-vnf-index: '2', vim_account: }]}'». <внешняя-VIM->параметр идентифицирует VIM внешнего сайта в стеке OSM. Параметр "--config" указывает, что все VNF, составляющие службу, должны быть развернуты на внешнем сайте, обрабатываемом этим VIM, за исключением VNF, идентифицированного индексом 2 в NS, который будет развернут на центральном сайте (VIM центрального сайта указан в параметр).
   4. Проверьте, что NS был развернут и его состояние с помощью команды "osm ns-list". Если создание экземпляра выполнено успешно, состояние изменится на "READY".
   5. Проверьте IP-адрес каждого из двух VNF с помощью "osm vnf-list" (необходимо для последующего входа в машины).
   6. Подключитесь к каждому VNF через SSH, используя команду «ssh fedora@» ( представляет собой IP-адрес VNF для подключения, полученный на предыдущем шаге). Введите пароль "fedora" при запросе SSH. После входа в обе машины проверьте их интерфейсы с помощью команды «ip address show» и получите IP-адреса на их интерфейсах, подключенных к сети поставщика данных (интерфейс eth1 в обоих VNF). Из одной из VNF выполните проверку связи с другой VNF, используя удаленный IP-адрес в сети поставщика данных. При наличии возможности подключения предварительный проверочный тест будет считаться успешным.

4. Валидация многосайтовой платформы NFV с реалистичным вертикальным сервисом

1. Загрузите изображения VNF из публичного репозитория и загрузите их в VIM соответствующего сайта (см. рисунок 3),следуя процедуре, описанной в шаге 3.3.12. В частности, на внешнем сайте будут размещены точка доступа VNF, маршрутизатор VNF, шлюз MQTT VNF и маршрутизатор доступа VNF. На центральном сайте будут размещены 5G Core VNF и IoT Server VNF.
2. Встроенные VNFD и NSD сервиса интеллектуального фермерства в стек OSM (все дескрипторы можно загрузить из репозитория экспериментов).
   1. Встроенная VNFD в стек OSM выполняет команду "osm vnfd-create " для каждого из VNF сетевой службы. В этом случае параметр соответствует имени файла пакета VNFD.
   2. Подключите NSD к стеку OSM с помощью команды "osm nsd-create ", где укажите имя файла пакета NSD (в данном эксперименте jove_uavs_scenario_nsd.tar.gz).
3. Разверните сетевую службу интеллектуального фермерства. Для этого выполните следующую команду из интерфейса командной строки OSM: osm ns-create --ns_name --nsd_name jove_uavs_scenario_nsd --vim_account --config '{vnf: [ {member-vnf-index: "5", vim_account: }, {member-vnf-index: "6", vim_account: } ], wim_account: False }'.
   ПРИМЕЧАНИЕ: Как указано на этапе 3.6.3, <внешняя-VIM-name>и <центральная-VIM-name>параметры указывают участки, где должны быть развернуты VNF. В частности, все VNF, составляющие сервис умного фермерства, будут размещены на новом внешнем сайте, за исключением тех, которые имеют индексы 5 и 6 (ядро 5G и VNF сервера IoT),которые будут выделены центральному сайту.
4. Убедитесь, что NS развернута, следуя той же процедуре, что и на шаге 3.6.4.
5. Получите доступ к IoT-серверу VNF с помощью команды «ssh mosquittosubscriber@» и проверьте его интерфейс, настроенный на связь с MQTT Gateway VNF через команду «ip address show dev eth1». IP-адрес VNF () можно получить, выполнив "osm vnf-list" в командной строке OSM.
6. Следуя аналогичной процедуре, получите доступ к шлюзу MQTT VNFи выполните команду "sudo python3 publisher_MQTT_GW.py -ma -ba ", где получен на предыдущем шаге, а вставая команду "ip-адрес show dev eth1" в шлюзе MQTT VNF. На этом шаге инициализируется MQTT Gateway VNF, который будет получать данные, сгенерированные датчиком с использованием стандарта MQTT^15,передавая эти данные на IoT-сервер VNF с использованием того же стандарта.
7. Подготовьте одноплатный компьютер (SBC), к которому подключен метеорологический датчик и с пропускной способностью приемопередатчика, для передачи показаний датчика в сторону шлюза MQTT VNF.
   ПРИМЕЧАНИЕ: В качестве примера этого протокола была использована модель SBC. Следовательно, следующие шаги, возможно, потребуется адаптировать в случае использования другой платформы SBC.
   1. Подключите (например, с помощью оловянных припаянных медных проводов) контакты платы датчика к контактам общего назначения ввода/вывода (GPIO) SBC, следуя схеме конфигурации, указанной на рисунке 5.
   2. Включите модуль ядра I2C в SBC, чтобы иметь возможность проверить, обнаружен ли датчик. Для этого выполните команду "sudo raspi-config", следуйте последовательности Параметры сопряжения -> I2C -> Да в отображаемом меню и перезагрузите SBC, чтобы изменения вступили в силу.
   3. Убедитесь, что датчик обнаружен Установка программного обеспечения i2c-tools в SBC и выполнение команды "sudo i2cdetect -y 1". Если это так, должна появиться сетка, указывающая положение, в котором обнаружен датчик.
   4. Установите соответствующие программные библиотеки, позволяющие SBC считывать и отправлять данные, предоставляемые датчиком. В частности, этот эксперимент использует библиотеки Python RPi.bme280³² и paho-mqtt^33.
8. Используя мобильное приложение SUAV, снимите воздушное судно, на котором размещена точка доступа VNF,и расположите его так, чтобы обеспечить беспроводное покрытие SBC с помощью датчика.
   ПРИМЕЧАНИЕ: Полет БПЛА с поддержкой NFV не зависит от эксплуатационного поведения сетевой службы, которая может работать независимо от того, летят ли БПЛА или находятся в состоянии покоя, чтобы уменьшить потребление батареи. Таким образом, шаг 4.8 является необязательным.
9. Подключите SBC, отвечающий за чтение данных, собранных датчиком, к беспроводной точке доступа Wi-Fi, предоставляемой точкой доступа VNF). После успешного подключения от датчика к шлюзу MQTT VNFбудет включен беспроводной сетевой путь.
10. Запустите передачу чувствительных данных, выполнив команду "python3 /home/ubuntu/sensorDataTransmission.py -a " в SBC, который включает в себя датчик ( является IP-адресом, полученным на шаге 4.6.).
11. Получите доступ к графическому веб-интерфейсу, предоставляемому сервером IoT VNF, чтобы проверить правильность приема в режиме реального времени отслеживаемых данных. С этой целью проверьте IP-адрес VNF сервера IoT с помощью команды «osm vnf-list» и введите следующий URL-адрес в веб-браузере: http://:3001, где — IP-адрес сервера IoT VNF. Затем нажмите кнопку «Сбор данных датчиков» на вкладке «Главная» и проверьте обновление графиков, включенных в панель мониторинга, в режиме реального времени по мере получения данных.
    ПРИМЕЧАНИЕ: Чтобы иметь доступ к URL-адресу, указанному в шаге 4.12, устройство с веб-браузером, пытающимся достичь этого ресурса, должно быть подключено к экосистеме NFV и иметь IP-подключение к IoT Server VNF. Для этой цели также можно использовать VPN-сервис.
12. Подождите соответствующий период времени, чтобы получить репрезентативные результаты выполнения услуги умного фермерства. Затем соберите данные, хранящиеся на сервере IoT VNF для дальнейшего анализа. Учитывая, что датчик, включенный в этот эксперимент, обеспечивает показания температуры, влажности и давления каждые 5 секунд, служба в эксперименте работает в течение 10 минут, в результате чего получается 180 образцов зондируемых данных (по 60 для каждого типа метеорологических значений).
13. Доступ к базе данных VNF сервера IoT для получения данных датчиков для дальнейшего анализа. Для этого выполните команду "id_database=$(sudo docker ps | grep 'influxdb:' | cut -d ' ' -f 1)" на сервере IoT VNF, а затем "sudo docker exec -it $id_database bash"
14. Экспортируйте данные в файл с разделителями-запятыми (CSV), выполнив команду "influx -database 'mainflux" -выполните "SELECT * FROM messages WHERE \"name\" = '' " -format csv > /tmp/.csv". Измените параметр чтобы выбрать, какой тип чувствительных данных следует экспортировать с «температурой», «влажностью» или «давлением», и задайте <имя файла>параметр, чтобы выбрать имя для выходного файла, в котором будут храниться результаты.
15. Сохраните файлы данных, сгенерированные на предыдущем шаге, для последующего представления (см. раздел «Репрезентативные результаты») и проверки правильной работы службы интеллектуального фермерства.

Representative Results

После тщательного соблюдения протокола для включения нового сайта в центральную платформу и запуска одного сетевого сервиса для проверки его надлежащей функциональности, на рисунке 6 показан снимок экрана инструмента open-vpn-monitor. Можно наблюдать, как новый сайт использует VPN для всех своих коммуникаций, показывая, как его коммуникации следуют за VPN, чтобы обеспечить этот обмен данными и, как следствие, правильное добавление нового сайта в VPN-сервис.

Как показано на рисунке 3,сетевая служба доставляет информацию от датчика, расположенного в удаленной инфраструктуре, к серверу, расположенному на центральном сайте. Кроме того, на рисунке 7 показано успешное развертывание сетевой службы из графического веб-интерфейса OSM, показывая, как можно правильно создать экземпляр эксперимента в новой удаленной инфраструктуре из стека MANO, расположенного на центральном сайте. Кроме того, время, необходимое в эксперименте для завершения развертывания службы, составляет около восьми минут. Это значение, наряду со временем, необходимым для включения дескрипторов сервиса в платформу оркестровки (около 9 секунд, с 1,3 секунды на дескриптор, учитывая как NS, так и каждый дескриптор VNF), позволяет удовлетворить ключевой показатель эффективности (KPI) 90 минут для времени создания сервиса, как указано в 5G Infrastructure Public Private Partnership^34. В этом контексте работа, представленная в Vidal et al.^9, включает в себя углубленный анализ времени создания сервиса с несколькими сайтами, использующими представленный протокол.

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

Рисунок 1: Распределение сайта VPN-сервиса. Распространение VPN-сервиса через платформу и их связное подключение (все проходит через 5TONIC). Пожалуйста, нажмите здесь, чтобы просмотреть увеличенную версию этого рисунка.

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

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

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

Рисунок 5:Схема конфигурирования выводов. Диаграмма, представляющая, как установить физические соединения между контактами платы датчиков и контактами GPIO SBC, который включает в себя этот датчик. Пожалуйста, нажмите здесь, чтобы просмотреть увеличенную версию этого рисунка.

Рисунок 6: Снимок OpenVPN-монитора. На рисунке видно, что агрегированная инфраструктура подключена к VPN-сервису, включая некоторые его детали, касающиеся его подключения. Кроме того, на рисунке также изображены дополнительные соединения, принадлежащие другим удаленным инфраструктурам. Пожалуйста, нажмите здесь, чтобы просмотреть увеличенную версию этого рисунка.

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

Рисунок 8: Репрезентативный анализ данных, собранных датчиком. (A) Иллюстрация данных о температуре, периодически собираемых датчиком каждые 5 секунд. (B) Графическое представление данных о влажности, собираемых датчиком каждые 5 секунд. (C) Визуальное изображение данных о давлении, собираемых датчиком каждые 5 секунд. Пожалуйста, нажмите здесь, чтобы просмотреть увеличенную версию этого рисунка.

Discussion

Одним из наиболее важных аспектов ранее описанного протокола является его выдающаяся гибкость для включения новых вычислительных инфраструктур в экосистему NFV, независимо от их распределения с точки зрения географического положения (при условии, что пропускная способность и задержка сетевых коммуникаций с удаленными сайтами поддерживают его). Это возможно благодаря архитектуре оверлейной сети на основе VPN, которая позволяет установить виртуальное соединение для подключения удаленных сайтов к центральным помещениям экосистемы NFV. Такой подход позволяет обеспечить эффективный и безопасный канал для поддержки NFV и передачи данных между сайтами экосистемы NFV, снижая вероятность того, что внешние стороны получат доступ и/или изменят конфиденциальную информацию о процессах оркестрации NFV и данных из развернутых сервисов. В этом контексте протокол также описывает конкретную методологию безопасного обмена учетными данными VPN с внешними сайтами, что позволит интегрировать новые инфраструктуры. Протокол был проиллюстрирован с использованием экосистемы NFV, доступной на 5TONIC Университетом Карлоса III де Мадрида, Telefónica и Институтом сетей IMDEA, хотя он является общим для использования в других средах NFV, удовлетворяющих предварительным требованиям, упомянутым на этапе 1 этого протокола.

Кроме того, стоит подчеркнуть исключительное использование инструментов с открытым исходным кодом и программного обеспечения для реализации протокола. Несмотря на потенциально полезные функциональные возможности, которые могут быть предложены различными проприетарными решениями (например, Fortinet^35),использование разработок с открытым исходным кодом облегчило интеграцию всех элементов, охватываемых протоколом, благодаря присущим им характеристикам, таким как экономическая эффективность, обширная поддержка программного обеспечения, предоставляемая сообществом с открытым исходным кодом, и высокий уровень надежности, и это лишь некоторые из них. Кроме того, использование технологий с открытыми исходными кодами может также способствовать синергизму между компонентами аналогичного характера. Например, для мониторинга состояния VPN-соединения для клиентов, использующих платформу, VPN-сервис, реализованный по всему протоколу, может полагаться на инструмент³⁶ мониторинга open-vpn (инструмент мониторинга на основе python, способный взаимодействовать с серверами OpenVPN).

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

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

Наконец, и учитывая выдающуюся производительность, которую эта платформа и ее VPN-сервис имели в европейских проектах и совместных работах, где она использовалась до сих пор (например, 5GINFIRE, 5GRANGE или 5GCity, упомянутые во введении к этому документу), она будет рассматриваться как важный элемент в новых европейских проектах, где Universidad Carlos III de Madrid, Telefónica и IMDEA Networks Institute участвуют, такие как Horizon 2020 LABYRINTH, или национальные проекты, такие как TRUE-5G.

Materials

Name	Company	Catalog Number	Comments
Bebop 2	Parrot		UAV used in the experiment to transport the RPis and thus, provide mobility to the compute units of external site.
BME280 Sensor	Bosch		Sensor capable of providing readings of the environmental conditions regarding temperature, barometric pressure, and humidity.
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 extternal aite. In addition, another unit of this equipment (along with the RPis) conforms the computational resources of the NFV insfrastrucure included in that site.
Iptables	Netfilter - Open source tool		(Software) An open source command line utility for configuring Linux kernel firewall rulset. Source-code available online: https://www.netfilter.org/projects/iptables/
Lithium Battery Pack Expansion Board. Model KY68C-UK	Kuman		Battery-power supply HAT (Hardware Attached on Top) for the UAV computation units composing the NFV infrastructure of the external site.
MacBook Pro	Apple		Commodity laptop utilized during the experiment to obtain and gather the results as described in the manuscript.
Mainflux	Mainflux Labs - Open source platform		(Software) Open source Internet of Things (IoT) platform used in the experiment for implementing the virtual network function called as IoT Server VNF. In addition, this platform includes an open-source software based on Grafana which allows the visualization and formatting of the metric data. Source code available online: https://www.mainflux.com/
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/docs/user-guide/
OpenStack - Release Ocata	OpenStack - Open source community		(Software) Open source software used for setting up both the NFV infrastrucure of the central site and the NFV infrastructure of external site within the experiment. Source-code available online: https://docs.openstack.org/ocata/install-guide-ubuntu
OpenVPN - Version 2.3.10	OpenVPN - Open source community		Open source software implementing the VPN service presented in the experiment for the creation of the overlay network that will enable the operations of the NFV ecosystem (providing connectivity among all the sites comprising the ecosystem). Source-code available online: https://openvpn.net/
Openvpn-monitor	Python - Open source software		(Software) Open source program based on Python code that allows the visualization of the state of the VPN service, as well as the representation of the sites that are connected at every instant. For this purpose, the program check priodically the information provided by the VPN server implemented with OpenVPN. Source-code available online: https://github.com/furlongm/openvpn-monitor
Paho-mqtt 1.5.0	Python - Open source library		(Software) Open source library developed in Python code that enables the trasmission of the data read by the sensor through the use of MQTT standard  Source-code available online: https://pypi.org/project/paho-mqtt/
Ping	Debian - 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 central site presented in the experiment.
Power Edge R430	Dell		High-profile computer server in charge of hosting the virtual private network (VPN) service. Note that the computing requirements for provisioning this service are high due to the resource consumption of the encryption operations present in the service.
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 of the central site 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.
Raspberry PI. Model 3b	Raspberry Pi Foundation		Selected model of Single Board Computer (SBC ) used for providing the computational capacity to the experiment's external site. In addition, this SBC model is used during the deployment of the included realistic service for interpreting and sending the data collected by a sensor.
RPi.bme280 0.2.3	Python - Open source library		(Software) Open source library developed in Python code that allows to interface the sensor Bosch BME280, and interpret the readings offered by that sensor. Source-code available online: https://pypi.org/project/RPi.bme280/