Integración de infraestructuras de experimentación 5G en un ecosistema NFV multisitio

Summary

El objetivo del protocolo descrito es apoyar la incorporación flexible de infraestructuras de experimentación 5G en un ecosistema NFV multisitio, a través de una arquitectura de red superpuesta basada en VPN. Además, el protocolo define cómo validar la efectividad de la integración, incluida una implementación de servicio vertical en varios sitios con vehículos aéreos pequeños con capacidad NFV.

Abstract

La virtualización de funciones de red (NFV) ha sido considerada como uno de los habilitadores clave para la^5ª generación de redes móviles, o 5G. Este paradigma permite reducir la dependencia de hardware especializado para desplegar telecomunicaciones y servicios verticales. Para ello, se apoya en técnicas de virtualización para softwarize las funciones de red, simplificando su desarrollo y reduciendo el tiempo y los costes de despliegue. En este contexto, la Universidad Carlos III de Madrid, Telefónica e IMDEA Networks Institute han desarrollado un ecosistema NFV dentro de 5TONIC, un centro de innovación de red abierta centrado en las tecnologías 5G, que permite la creación de escenarios de experimentación complejos y cercanos a la realidad a través de un conjunto distribuido de infraestructuras NFV, que pueden ser puestos a disposición por los grupos de interés en diferentes ubicaciones geográficas. Este artículo presenta el protocolo que se ha definido para incorporar nuevos sitios NFV remotos en el ecosistema NFV multisitio basado en 5TONIC, describiendo los requisitos tanto para las infraestructuras existentes como para las recién incorporadas, su conectividad a través de una arquitectura de red superpuesta y los pasos necesarios para la inclusión de nuevos sitios. El protocolo se ejemplifica a través de la incorporación de un sitio externo al ecosistema 5TONIC NFV. Posteriormente, el protocolo detalla los pasos de verificación necesarios para validar una integración exitosa del sitio. Estos incluyen el despliegue de un servicio vertical de múltiples sitios utilizando una infraestructura NFV remota con pequeños vehículos aéreos no tripulados (SUAV). Esto sirve para mostrar el potencial del protocolo para permitir escenarios de experimentación distribuida.

Introduction

La introducción de la quinta generación de redes móviles (5G) ha supuesto revolucionar la industria de las telecomunicaciones desde principios de la década, obligando a los operadores de telecomunicaciones a abordar las especificaciones mucho más exigentes de los nuevos servicios y aplicaciones de redes desarrollados bajo el paraguas 5G^1,2 . Estas nuevas especificaciones incluyen, entre otras, aumentos de la velocidad de datos, mejoras en la latencia de transmisión inalámbrica y reducción de los costos operativos. Entre las tecnologías que constituyen las bases de las mejoras para esta nueva generación, Network Functions Virtualization³ (NFV) se ha convertido en uno de sus facilitadores clave. NFV proporciona la capacidad de softwarize funciones de red, tradicionalmente retransmitiendo en hardware especializado, mediante el uso de equipos físicos de propósito genérico en su lugar, como computadoras servidor en un centro de datos. Con este nuevo paradigma, los operadores de telecomunicaciones y las industrias verticales pueden implementar funciones y servicios de red como un conjunto de componentes de software, y ahorrar costos tanto en la implementación como en el mantenimiento del servicio, además de facilitar una elasticidad de infraestructura de red mucho mayor. Este enfoque alivia o elimina la necesidad de utilizar dispositivos dedicados (y generalmente más complejos y menos reutilizables) para la mayoría de las funciones específicas de red y verticales, y admite un grado mucho mayor y más denso de automatización operativa, lo que reduce los costos de implementación y mantenimiento.

Teniendo en cuenta todas las ventajas que un entorno NFV es capaz de proporcionar, es natural que un gran número de partes interesadas relevantes del sector de las telecomunicaciones hayan participado cada vez más en la prueba de nuevas ideas de servicios en entornos NFV. En este contexto, Telefónica e IMDEA Networks Institute han creado 5TONIC^4,un laboratorio abierto de investigación e innovación centrado en las tecnologías 5G. Con sede en Madrid (España), este laboratorio cuenta con una amplia gama de tecnologías disponibles para investigadores y socios para impulsar el desarrollo y validación de servicios 5G. En particular, este laboratorio tiene una plataforma NFV experimental donde los desarrolladores pueden implementar y probar sus nuevas aplicaciones y servicios basados en NFV en un ecosistema NFV compatible con ETSI⁵. Por lo tanto, las conclusiones experimentales sobre las opciones de diseño y las propuestas tecnológicas se pueden derivar en un entorno realista y mucho más flexible que las redes de producción. Esta plataforma ha sido diseñada para soportar actividades de experimentación en múltiples sitios externos, que pueden estar interconectados de manera flexible a 5TONIC utilizando un protocolo bien definido.

La solución técnica adoptada para el ecosistema 5TONIC NFV considera la utilización de un único orquestador NFV, implementado utilizando el software Open Source MANO (OSM) alojado en ETSI⁶. Este es el elemento encargado de gestionar y coordinar el ciclo de vida de los Servicios de Red (NS). Estos servicios se pueden construir como una composición de Virtualized Network/Vertical Functions (VNF), que se puede implementar en cualquiera de los sitios integrados en la plataforma NFV. El diseño del ecosistema 5TONIC NFV se ha realizado en el contexto del proyecto H2020 5GINFIRE⁷,^8,donde la plataforma se utilizó para apoyar la ejecución de más de 25 experimentos, seleccionados a través de un proceso competitivo de convocatoria abierta, a través de ocho infraestructuras experimentales verticales específicas ubicadas en Europa y una en Brasil, esta última conectada a través de un enlace transoceánico. Además, la plataforma se aprovechó para construir un banco de pruebas NFV distribuido a escala nacional, en España, apoyando las actividades de experimentación dentro del proyecto español 5GCity^9,10. Más recientemente, se ha integrado un sitio brasileño adicional en la plataforma, para apoyar actividades de demostración conjuntas en el contexto de una cooperación de investigación e innovación establecida entre Brasil y Europa (es decir, el proyecto 5GRANGE^11,12). Por último, pero no menos importante, la infraestructura se ha utilizado para apoyar experimentos de terceros en el ámbito del proyecto 5G-VINNI^13,14. La distribución geográfica de la plataforma NFV se puede ver en la Figura 1.

Las organizaciones interesadas que alojan su propia infraestructura NFV pueden conectarse de manera flexible al ecosistema 5TONIC NFV, sujeto a la aprobación de la Junta Directiva de 5TONIC, convertirse en proveedores de bancos de pruebas dentro del ecosistema distribuido y participar en actividades conjuntas de experimentación y demostración. Para ello, deben contar con un VIM (Virtual Infrastructure Manager) compatible con la pila de software OSM. El orquestador 5TONIC NFV es capaz de interactuar con los VIMs en los sitios involucrados en una implementación de servicio determinada, coordinando la asignación y configuración de los recursos informáticos, de almacenamiento y de red necesarios para la creación de instancias e interconexión de los VNF que componen un servicio de red, y controlando su ciclo de vida, desde su incorporación hasta su desmantelamiento final.

Para gestionar el intercambio de control y el tráfico de datos dentro de todos los sitios interconectados, el ecosistema 5TONIC NFV hace uso de una arquitectura de red superpuesta basada en Redes Privadas Virtuales (VPN). Este enfoque proporciona acceso seguro basado en PKI a los sitios externos que están integrados en el ecosistema 5TONIC, lo que permite el intercambio de información de control NFV entre la pila de software OSM y los diferentes VIM distribuidos en los bancos de pruebas, así como el intercambio de información que se requiere para administrar y configurar todos los VNF. Además, esta red superpuesta admite la difusión del tráfico de datos entre VNF que se implementan en diferentes sitios.

En este contexto, este documento detalla el protocolo diseñado para incorporar un sitio externo a un ecosistema NFV. El protocolo asume que el ecosistema está gobernado por un único orquestador NFV, instalado en un sitio central, y los sitios externos cuentan con una solución VIM compatible con la pila de software de orchestrator. El protocolo propuesto permite incrementar la cartera de recursos del ecosistema experimental, con la incorporación flexible de sitios NFV e infraestructuras verticales específicas. Esto permite la creación de una plataforma MANO distribuida capaz de probar y validar nuevos servicios verticales y de red en múltiples sitios, bajo el control de un solo orquestador NFV. Con el fin de ilustrar el funcionamiento interno del protocolo, el proceso se ejemplificará agregando un sitio NFV externo al ecosistema actual de 5TONIC NFV, describiendo los componentes necesarios en el sitio externo y 5TONIC, así como todos los pasos a seguir durante el proceso de integración. La Figura 2 proporciona una visión general del objetivo de la integración, con el nuevo banco de pruebas basado en NFV conectado a la plataforma 5TONIC desde donde se pueden desplegar los servicios de red, mediante conexiones VPN entre el sitio central y el resto de las infraestructuras externas.

Además, para mostrar la efectividad del protocolo, se mostrará el despliegue de un servicio vertical simple, utilizando el ecosistema 5TONIC y un sitio externo con pequeños vehículos aéreos no tripulados (SUAV) con capacidad NFV. El diseño del servicio vertical se ha inspirado en un experimento presentado en Vidal et al.^9,que se ha simplificado a efectos ilustrativos de este trabajo. La Figura 3 describe el servicio, que tiene como objetivo ayudar a las actividades agrícolas inteligentes en un área remota. El servicio considera un proveedor de servicios de agricultura inteligente que utiliza SUAV para recopilar y difundir los datos producidos por sensores meteorológicos dispersos en un campo de cultivo. Para simplificar, el experimento presentado en el documento considera un solo SUAV y un sensor, capaces de proporcionar mediciones de temperatura, humedad y presión. En el experimento, el sitio NFV externo hospeda un punto de acceso Wi-Fi que se implementa como VNF a través del SUAV. Este VNF ofrece conectividad de acceso a la red al sensor, reenviando los datos detectados hacia una función de puerta de enlace. Este último se despliega como un VNF en un equipo terrestre (una computadora mini-ITX). La difusión de datos del sensor a la función de puerta de enlace sigue un enfoque de publicación/suscripción basado en el protocolo de transporte de telemetría de Message Queue Server (MQTT)¹⁵. La función de puerta de enlace procesa y luego difunde los datos hacia un servidor de Internet de las cosas (IoT), que está disponible como VNF en el sitio central del ecosistema NFV, basado en la plataforma de código abierto Mainflux^16. Finalmente, el escenario asume un área remota donde la conectividad a Internet es proporcionada por una red de acceso celular no 3GPP. Por lo tanto, el servicio incluye dos VNF adicionales: 1) un enrutador de acceso VNF, que implementa la pila de protocolos de plano de usuario de un equipo de usuario 3GPP conectado a una red de acceso que no es 3GPP¹⁷; y 2) una implementación de referencia de una red central 5G, que admita el envío de información entre el enrutador de acceso y los VNF del servidor IoT. Con este propósito, el núcleo 5G VNF proporciona una implementación simplificada del plano de usuario de una función de interfuncionamiento no 3GPP y una función de plano de usuario, según lo definido por 3GPP^17.

Finalmente, la Figura 4 representa los procesos más relevantes involucrados durante el desarrollo del protocolo, destacando sus interconexiones lógicas y las entidades encargadas de su ejecución.

Protocol

1. Provisión del sitio central del ecosistema NFV (requisitos previos del experimento)

1. Asigne un espacio de direcciones IP para que lo use el sitio central. A los efectos de este protocolo, se utilizará el espacio de direcciones privadas 10.4.0.0/16.
2. Instale la pila de software de administración y orquestación (MANO) en el sitio central. En concreto, el experimento llevado a cabo a lo largo de este protocolo utiliza el Open Source MANO (OSM) Release SEVEN^18,que requiere los siguientes recursos: Ubuntu 18.04 como sistema operativo, 2 Unidades Centrales de Procesamiento (CPUs), 8 GB de Memoria de Acceso Aleatorio (RAM), disco duro de 40 GB, y al menos una interfaz de red con acceso a Internet. Para la instalación, siga las instrucciones disponibles en la documentación de OSM Release SEVEN¹⁸.
3. Configure un Administrador de infraestructura virtual (VIM) compatible con OSM en el sitio central. En concreto, el experimento utiliza openStack versión Ocata^20,ejecutándose en una máquina virtual (VM) con Ubuntu 16.04, 4 CPUs, 16 GB de RAM y 200 GB de disco duro. La infraestructura NFV (NFVI) manejada por este VIM comprende tres computadoras servidor, cada una con Ubuntu 16.04, 8 CPU, 32 GB de RAM y 2 TB de almacenamiento. Para la instalación, siga la documentación de la versión de Ocata²¹.
   1. Implemente una red virtual dentro de la plataforma en la nube OpenStack, utilizando un intervalo de direcciones IP del espacio de direcciones asignado en el paso 1.1. Esta red, en adelante denominada red de gestión, se utilizará para admitir el intercambio de información de orquestación NFV entre el OSM y las funciones de red virtual (VNF) instanciadas en el sitio central.
   2. Configure una red virtual (en adelante denominada red de datos) para admitir las comunicaciones de datos entre sitios, entre los VNF del sitio central y otros VNF ejecutados en sitios externos. Con este fin, utilice un intervalo de direcciones IP del espacio de direcciones del paso 1.1.
      NOTA: La implementación de las redes mencionadas en los pasos 1.3.1 y 1.3.2 se ha realizado utilizando redes proveedoras de OpenStack. Las redes de los proveedores deben estar conectadas a la infraestructura de red física del sitio central para garantizar un funcionamiento adecuado.
4. Conecte tanto las redes privadas virtuales (es decir, la administración y las redes de datos), como las máquinas VIM y OSM, a un equipo que proporcione funcionalidades de enrutamiento perimetral. Este enrutador servirá como punto de entrada al sitio central del ecosistema NFV.
5. Poner a disposición un repositorio público de experimentos para proporcionar todo el contenido necesario para llevar a cabo el experimento. En particular, este protocolo utiliza el repositorio público en²².

2. Configuración del servicio de red privada virtual

1. Asigne un espacio de direcciones IP para respaldar el funcionamiento adecuado del ecosistema de múltiples sitios, de modo que las comunicaciones de red se puedan establecer de manera efectiva entre múltiples sitios.
   NOTA: Habilitar comunicaciones de red efectivas entre múltiples sitios requiere un diseño cuidadoso del espacio de direcciones IP que utilizará el ecosistema NFV, así como los sitios externos que necesitan conectarse a él. En particular, el espacio de direcciones asignado para las comunicaciones entre sitios no debe colisionar con el espacio de direcciones ya en uso en cualquier otro sitio para otros fines.
   1. Asigne un espacio de direcciones IP para que lo usen sitios externos. Las direcciones de este bloque se asignarán a entidades NFV (por ejemplo, VIM) y VNF del sitio externo. Para ejemplificar este protocolo, se utilizará el espacio de direcciones privadas 10.154.0.0/16.
   2. Asigne un espacio de direcciones IP a los vínculos virtuales entre los sitios externos y el ecosistema NFV. Estos enlaces virtuales serán compatibles con un servicio VPN. Para ejemplificar este protocolo, se utilizará el rango de direcciones 10.154.254.0/24 para estos enlaces virtuales.
2. Configure un equipo para proporcionar el servicio de red privada virtual (VPN) (es decir, un servidor VPN). En particular, el experimento utiliza una computadora servidor con Ubuntu 16.04 (imagen variante de 64 bits), seis CPU independientes, 16 GB de RAM, 1 TB de disco de almacenamiento y dos interfaces de red.
   1. Configure una de las interfaces de red del servidor VPN para permitir la recepción de solicitudes de conexión de sitios externos a través de Internet. Para ello, es necesario utilizar una interfaz del servidor configurada con una dirección IP pública.
   2. Configure el vínculo entre el servidor VPN y el enrutador perimetral del sitio central. En el experimento, a este enlace se le asignó el rango de direcciones 10.4.255.0/24. Configure las rutas de red adecuadas en el servidor VPN, de modo que el ecosistema NFV sea accesible desde sitios externos conectados al servicio VPN.
3. Instale el software VPN de código abierto proporcionado por el proyecto OpenVPN²³ en el servidor VPN. En concreto, este experimento utiliza la versión 2.3.10 de OpenVPN, y su despliegue se realizó con el script bash "openvpn-install.sh", disponible en http://github.com/Nyr/openvpn-install (otras opciones de instalación se describen en la documentación de OpenVPN ^24). El script bash presenta los parámetros alternativos que darán como resultado la configuración del servicio VPN.
   1. Seleccione la dirección IP para escuchar las solicitudes de conexión VPN (es decir, la dirección IP pública).
   2. Decida qué protocolo (UDP o TCP) se debe utilizar para dirigir las comunicaciones a través de la VPN. En este caso, el experimento aprovecha UDP que es el protocolo recomendado.
   3. Especifique el puerto que comprenderá el duple (junto con la dirección IP pública) que se utilizará para recibir las solicitudes de conexión de servicio. De forma predeterminada, el valor asignado es 1194.
   4. Elija uno de los servidores DNS de la lista solicitados por el asistente que gestionará las solicitudes de resolución de nombres realizadas por los clientes del servicio VPN.
   5. Presione cualquier tecla para habilitar el inicio automático del proceso de instalación del servicio VPN.
4. Edite el archivo de configuración "server.conf" que se encuentra en el directorio "/etc/openvpn/server/" e incluya la directiva "client-to-client" con el objetivo de ampliar la configuración básica proporcionada por el paso 2.3. Por lo tanto, los diferentes clientes conectados al servicio VPN podrán comunicarse entre sí.
5. Habilite la configuración de cliente individual dentro de la configuración de VPN para poder administrar de forma independiente las asignaciones de enrutamiento para cada cliente.
   1. Agregue la directiva "client-config-dir ccd", editando el mismo archivo de configuración que en el paso 2.4.
   2. Cree el directorio "ccd" usando el comando "mkdir /etc/openvpn/ccd/". Este directorio servirá durante la siguiente sección del protocolo para colocar los archivos que componen las directivas de enrutamiento asociadas a los clientes destinados a ser integrados dentro de la plataforma.
6. Configure las reglas de firewall necesarias para permitir las conexiones con el servicio, al tiempo que protege el servidor VPN contra ataques maliciosos. Con ese fin, este experimento aprovecha iptables^25,que es una utilidad de línea de comandos desarrollada para configurar el firewall del kernel de Linux.
   1. Primero, bloquee el tráfico entrante al servidor VPN con el comando "iptables -P INPUT DROP".
   2. Permitir la recepción de solicitudes de conexión VPN con los comandos "iptables -A INPUT -i -m state --state NEW -p udp --dport 1194 -j ACCEPT" ( es el nombre de la interfaz del servidor VPN con la dirección IP pública) e "iptables -A INPUT -i tun+ -j ACCEPT".
   3. Permitir el reenvío de tráfico entre las interfaces del servidor VPN (es decir, la interfaz pública y la interfaz virtual creada por el servicio VPN llamado tun0), para permitir que el servidor VPN procese la solicitud de conexión del servicio. Para ello, ejecute el comando "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. Permitir que el servidor VPN proporcione la capacidad de traducción de direcciones de red (NAT) con el objetivo de proporcionar acceso a Internet al sitio central, ejecutando: "iptables -t nat -A POSTROUTING -s 10.4.0.0/16 -o -j MASQUERADE && iptables -A OUTPUT -o tun+ -j ACCEPT".

3. Integración de un sitio NFV externo

1. Obtenga un rango de direcciones IP adecuado para integrar el sitio en el ecosistema NFV. Este rango de direcciones será proporcionado por el centro de operaciones de red del ecosistema NFV. De acuerdo con el paso 2.1.1 de este protocolo, el experimento utilizará un rango de direcciones IP para el sitio externo dentro de 10.154.0.0/16.
2. Cree y proporcione las credenciales de seguridad para conectarse al ecosistema NFV.
   1. Genere una credencial de VPN que permita a la nueva infraestructura establecer una conexión segura con el servidor VPN. Para este propósito, ejecute el comando "bash openvpn-install.sh" en el servidor VPN, seleccione la opción "1) Agregar un nuevo cliente" de la lista solicitada y proporcione el nombre que se asociará con esa credencial, por ejemplo, uc3m_infrastructure. Este paso generará un archivo con las credenciales de VPN (denominado "uc3m_infrastructure.ovpn" en el ejemplo).
   2. Cree un archivo de texto en el directorio "/etc/openvpn/ccd/" del servidor VPN, incluidas las directivas de enrutamiento (como se especifica en la documentación de OpenVPN ²⁴⁾que debe ser enviada por el servidor VPN cada vez que se establece una conexión al servicio VPN utilizando las credenciales de VPN.
      NOTA: El nombre del archivo de texto debe coincidir con el nombre especificado durante la creación de la credencial VPN (por ejemplo, uc3m_infrastructure) para proporcionar una configuración personalizada para cada cliente VPN.
   3. Proporcione el archivo de credenciales de VPN al personal técnico del sitio externo. Esto debe hacerse a través de un canal seguro y confiable. En este experimento, se utiliza un proceso de cifrado manual. Para cifrar la credencial vpn, ejecute el comando "7za a -tzip '-p' -mem=AES256 ", estableciendo como la clave de cifrado deseada, como el nombre elegido para el archivo cifrado y como el nombre de archivo del archivo de credenciales vpn (por ejemplo, uc3m_infrastructure.ovpn).
   4. Proporcionar la credencial cifrada al personal técnico del nuevo sitio, junto con la clave que permite los procedimientos de descifrado, a través de un canal de comunicaciones seguro.
      NOTA: En este experimento, las credenciales cifradas se proporcionaron por correo electrónico, mientras que la clave de descifrado se envió a través de un canal separado, utilizando el servicio de mensajes cortos (SMS), con un acuerdo fuera de línea del número de teléfono.
3. Configure el entorno en el nuevo sitio, para establecer la conexión con el ecosistema NFV y permitir que el NFVI remoto se conecte a la pila OSM del sitio central.
   1. Instale el software VPN proporcionado por OpenVPN²⁴ en una computadora, para habilitar un enlace virtual entre el sitio externo y el sitio central del ecosistema NFV. La computadora con el software OpenVPN servirá como cliente VPN o punto final VPN en el sitio externo. El enlace virtual se realizará mediante un túnel VPN protegido entre el punto final de VPN y el servidor VPN. En el experimento, el punto final de VPN se ejecuta en una computadora servidor con Ubuntu 18.04, 8 CPU, 8 GB de RAM, disco de almacenamiento de 128 GB e interfaces de 3 GbE (una para conectarse con el servicio VPN a través de Internet).
   2. Active el reenvío de IP en el punto de conexión VPN para admitir las capacidades de enrutamiento de red. Para ello, incluya la línea "net.ipv4.ip_forward=1" en el archivo de configuración del sistema ubicado en la ruta "/etc/sysctl.conf", y cargue la configuración actualizada con el comando "sudo sysctl -p".
   3. Descifre el archivo de credenciales de VPN con la información recibida en el paso 3.2.4, utilizando el comando "7za e ", donde el es el nombre de archivo de la credencial de VPN cifrada. Especifique la clave de descifrado cuando se lo solicite el comando.
   4. Arranque el software OpenVPN con el archivo de credenciales descifrado utilizando el comando "sudo openvpn --config " ( es el nombre de archivo de la credencial VPN). Con esto, el punto de conexión vpn se autenticará en el servidor VPN y recibirá automáticamente los parámetros de configuración de VPN y las rutas de red apropiados. De esta manera, el punto final de VPN se comportará como un enrutador de borde con un enlace virtual al sitio central del ecosistema NFV.
   5. Verifique el correcto funcionamiento del punto final de VPN, utilizando el comando ping para verificar la disponibilidad de conectividad a uno de los nodos del sitio central (por ejemplo, el equipo de pila OSM).
   6. En el nuevo sitio, seleccione un VIM compatible con OSM para permitir las operaciones con la plataforma MANO. Para este experimento, se utiliza la versión de OpenStack Ocata.
      NOTA: OSM Release SEVEN admite los siguientes administradores de infraestructura virtual: OpenStack, OpenVIM^26,vCloud Director²⁷de VMware, Amazon Web Service^28,Microsoft Azure²⁹y Eclipse fog05³⁰ (consulte la documentación de OSM¹⁸ para obtener detalles de configuración específicos).
   7. Instale la versión de OpenStack Ocata²⁰ (consulte los procedimientos detallados en la documentación de la versión²¹).
   8. Implemente la infraestructura NFV en el sitio externo y conéctela al VIM. En particular, este experimento utiliza una infraestructura NFV que comprende tres computadoras de placa única (SBC), cada una con una capacidad de cómputo de 1 GB de RAM, 4 CPU y un disco de almacenamiento de 32 GB; y un único ordenador mini-ITX con 8 CPUs, 8 GB de RAM y 128 GB de almacenamiento.
      NOTA: El sitio externo ejemplificado en este protocolo se basa en una infraestructura NFV de vehículos aéreos no tripulados (SUAV) pequeños con capacidad NFV. Los detalles seguidos para habilitar dicha infraestructura se proporcionan en Nogales et al³¹. Los pasos 3.3.6 a 3.3.8 son opcionales, ya que es posible que ya exista una infraestructura NFV en el sitio externo.
   9. Cree un proyecto OpenStack para especificar el conjunto de recursos computacionales del sitio externo que se integrará en el ecosistema NFV. Para ello, acceda a la interfaz gráfica de usuario (GUI) proporcionada por OpenStack, inicie sesión en el sistema con las credenciales de administrador, haga clic en el botón + Crear proyecto de la pestaña Identidad -> Proyectos y cree un proyecto completando el formulario mostrado con la información solicitada.
   10. Cree un usuario válido que administre el proyecto creado en el paso anterior. Para ello, acceda a la pestaña Identidad -> Usuarios con el mismo inicio de sesión que en el paso anterior, haga clic en + Crear usuario y complete los campos obligatorios del formulario mostrado (nombre de usuario y contraseña), seleccionando el nuevo proyecto creado como proyecto principal y eligiendo el rol de administrador.
   11. Modifique las reglas de seguridad para permitir permisos de comunicación VNF en el nuevo sitio (en particular, habilite el tráfico SSH e ICMP). Para ello, acceda a la GUI de OpenStack con las credenciales del usuario creado en el paso anterior, siga la secuencia: Proyecto -> Red -> Grupos de seguridad -> + Agregar regla,y seleccione la opción SSH del menú desplegable Regla. Repita el proceso pero seleccionando la opción Todos los ICMP incluida en el menú desplegable.
   12. Descargue las imágenes de un servicio de prueba ofrecido por la comunidad OSM, el servicio de red Ping Pong ("Fedora-x86_64-20-20131211.1-sda-ping" y "Fedora-x86_64-20-20131211.1-sda-pong") desde el repositorio público de experimentos, y cárguelas en el VIM del sitio externo. Para ello, siga la secuencia Proyecto -> Calcular -> Imágenes -> + Crear imagen,y cree las imágenes utilizando el formulario mostrado y seleccionando cada una de las imágenes.
   13. Asigne dos intervalos de direcciones IP dentro del espacio de direcciones del sitio externo (asignado en el paso 3.1). Estos rangos se utilizarán para apoyar la gestión de los VNF del sitio externo y para permitir la comunicación de datos entre sitios entre VNF, respectivamente.
   14. Cree una red de proveedores(control-proveedor)utilizando el VIM. Esta red admitirá comunicaciones NFV entre la pila OSM en el sitio central y los VNF implementados en el nuevo sitio para fines de administración. Este tipo de comunicaciones también permitirá a la pila OSM configurar VNF después de su implementación. Para crear una red de proveedores en OpenStack, siga la secuencia Admin -> System -> Networks -> + Create Network y complete los detalles de la nueva red, utilizando el rango de direcciones IP seleccionado en el paso anterior.
   15. Cree una segunda red de proveedores(proveedor de datos)utilizando el VIM. Esta red apoyará las comunicaciones de datos entre los VNF del sitio y otros VNF del ecosistema NFV. Para crear esta red de proveedores en OpenStack, siga la secuencia Admin -> System -> Networks -> + Create Networky complete los detalles de la nueva red utilizando el intervalo de direcciones asignado.
       NOTA: Las instrucciones sobre cómo crear redes virtuales variarán según el software VIM. Consulte la documentación de su software respectivo para obtener más detalles.
   16. Comparta la información relacionada con VIM (en particular, el nombre de usuario / contraseña y el proyecto creado en los pasos 3.3.9 y 3.3.10) con el personal técnico del sitio central, para habilitar la conexión del VIM a la pila de software OSM.
4. Conecte la infraestructura NFV externa a la pila de software OSM del sitio central, utilizando la información obtenida del paso 3.3.16.
   1. Verifique la conectividad entre la pila OSM del sitio central y el VIM del nuevo sitio, utilizando la herramienta ping.
   2. Si la prueba de conectividad anterior se realiza correctamente, conecte el VIM externo a la pila OSM del sitio central. Para ello, utilice el siguiente comando en el equipo OSM: "osm vim-create --name --user --password --auth_url --tenant --account_type ". En este comando: es el nombre seleccionado para identificar el VIM dentro de la pila OSM, es el nombre del usuario autorizado para manejar los recursos del sitio externo (consulte el paso 3.3.10), es la contraseña del usuario indicado, < URL de autenticación> es el enlace a la API puesta a disposición por el VIM para habilitar las solicitudes de la pila OSM, es el nombre del proyecto definido en el paso 3.3.9 y es el software VIM utilizado (en este experimento, OpenStack).
5. Verifique la conexión adecuada del nuevo VIM a la pila OSM del ecosistema NFV.
   1. Ejecute el comando "ro_id=$(docker ps | grep osm_ro | cut -d ' ' -f 1)" para identificar el identificador del contenedor que implementa el módulo Resource Orchestrator (RO) dentro del sistema OSM. Este módulo es el responsable de interactuar con los VIMs con el fin de coordinar y asignar los recursos necesarios en el despliegue de los servicios de red posteriores.
   2. Acceda al contenedor RO utilizando el comando "docker exec -it $ro_id bash". Este comando utiliza el identificador obtenido en la ejecución del paso anterior.
   3. Compruebe que el nuevo VIM está incluido en la lista de centros de datos disponibles, utilizando el comando "openmano datacenter-list". El nuevo sitio debe aparecer en la lista con el mismo nombre que el introducido anteriormente en el paso 3.4.2 con el parameter.
   4. Enumere las imágenes que se han cargado en el VIM del sitio externo, utilizando el comando "openmano vim-image-list --datacenter ". El parámetro indica el nombre seleccionado para identificar el VIM dentro de la pila OSM. Si la ejecución de este comando se realiza correctamente, la conectividad con el VIM externo se ha establecido correctamente. Compruebe que las imágenes de Ping Pong están incluidas en la lista.
   5. Enumere las redes disponibles en el nuevo sitio con el comando "openmano vim-net-list --datacenter ". Compruebe que el proveedor de control y el proveedor de datos estén presentes.
6. Realizar una validación preliminar de la correcta integración del nuevo sitio, utilizando un servicio de prueba ofrecido por la comunidad OSM (todo el contenido al respecto está incluido dentro del repositorio de experimentos). Para ello, los comandos incluidos en los siguientes pasos se ejecutarán en el equipo que aloja la pila OSM.
   1. Incorpore los descriptores VNF (VNFD) a la pila OSM que ejecuta el comando "osm vnfd-create " para cada uno de los VNF que componen el servicio de prueba ( corresponde al nombre de archivo del paquete VNFD).
   2. Incorpore el descriptor NS (NSD) del servicio de prueba con el comando "osm nsd-create ", donde indica el nombre de archivo del paquete NSD (en este experimento, ping_pong_ns.tar.gz)".
   3. Inicie la instanciación del Servicio de Red de Ping Pong (NS) en los sitios externos y centrales, usando el comando "osm ns-create --ns_name --nsd_name ping_pong_ns --vim_account --config '{vnf: [{member-vnf-index: '2', vim_account: }]}'". El parámetro identifica el VIM del sitio externo dentro de la pila OSM. La opción "--config" indica que todos los VNF que componen el servicio deben implementarse en el sitio externo manejado por ese VIM, excepto el VNF identificado por el índice 2 en el NS, que se implementará en el sitio central (el VIM del sitio central se especifica en el parameter).
   4. Compruebe que el NS se ha implementado y su estado mediante el comando "osm ns-list". Si la instanciación se realiza correctamente, el estado cambiará a "LISTO".
   5. Compruebe la dirección IP de cada uno de los dos VNF con "osm vnf-list" (necesario para iniciar sesión en las máquinas posteriormente).
   6. Conéctese a cada VNF a través de SSH, utilizando el comando "ssh fedora@" ( representa la dirección IP del VNF al que conectarse, obtenida en el paso anterior). Introduzca la contraseña "fedora" cuando SSH se lo solicite. Una vez que haya iniciado sesión en ambas máquinas, verifique sus interfaces utilizando el comando "ip address show" y obtenga las direcciones IP en sus interfaces conectadas a la red del proveedor de datos (interfaz eth1 en ambos VNF). Desde uno de los VNF, realice un ping al otro VNF, utilizando la dirección IP remota de la red del proveedor de datos. Si hay conectividad, la prueba de validación preliminar se considerará exitosa.

4. Validación de la plataforma multisitio NFV con un servicio vertical realista

1. Descargue las imágenes VNF del repositorio público y cárguelas en el VIM de su sitio correspondiente (consulte la Figura 3),siguiendo el procedimiento detallado en el paso 3.3.12. En particular, el sitio externo alojará el punto de acceso VNF, router VNF, MQTT Gateway VNF y Access Router VNF. El sitio central alojará el 5G Core VNF y el IoT Server VNF.
2. Incorpore los VNFD y el NSD del servicio de agricultura inteligente a la pila OSM (todos los descriptores se pueden descargar desde el repositorio de experimentos).
   1. Incorpore los VNFD a la pila OSM ejecutando el comando "osm vnfd-create ", para cada uno de los VNF del servicio de red. En este caso, el parameter corresponde al nombre de archivo del paquete VNFD.
   2. Incorpore el NSD a la pila OSM con el comando "osm nsd-create ", donde indica el nombre de archivo del paquete NSD (en este experimento, jove_uavs_scenario_nsd.tar.gz).
3. Implemente el servicio de red de agricultura inteligente. Para ello, ejecute el siguiente comando desde la interfaz de línea de comandos de 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 }'.
   NOTA: Como se indica en el paso 3.6.3., los parámetros y indican los sitios donde se van a implementar los VNF. En particular, todos los VNF que componen el servicio de agricultura inteligente se colocarán en el nuevo sitio externo, excepto aquellos con índice 5 y 6 (el núcleo 5G y los VNF del servidor IoT)que se asignarán al sitio central.
4. Compruebe que se ha implementado el NS, siguiendo el mismo procedimiento que en el paso 3.6.4.
5. Acceda al servidor IoT VNF con el comando "ssh mosquittosubscriber@" y compruebe su interfaz configurada para comunicarse con MQTT Gateway VNF a través del comando "ip address show dev eth1". La dirección IP del VNF () se puede obtener ejecutando la "osm vnf-list" en la línea de comandos de OSM.
6. Siguiendo un procedimiento análogo, acceda a MQTT Gateway VNFy ejecute el comando "sudo python3 publisher_MQTT_GW.py -ma -ba " donde se obtiene el en el paso anterior, y el ejecutando el comando "ip address show dev eth1" en mqTT Gateway VNF. Este paso inicializa mqTT Gateway VNF,que recibirá los datos generados por el sensor utilizando el estándar MQTT^15,transmitiendo estos datos al servidor IoT VNF utilizando el mismo estándar.
7. Prepare un ordenador de placa única (SBC) que conecte un sensor meteorológico y con capacidad de transceptor para transmitir las lecturas del sensor hacia el VNF mqTT Gateway.
   NOTA: Para ejemplificar este protocolo, se ha utilizado un modelo SBC en particular. Por lo tanto, es posible que los siguientes pasos deban adaptarse en caso de utilizar una plataforma SBC diferente.
   1. Conecte (por ejemplo, utilizando cables de cobre soldados con estaño) los pines de la placa del sensor a los pines de entrada/salida de uso general (GPIO) del SBC, siguiendo el esquema de configuración de la Figura 5.
   2. Habilite el módulo del kernel I2C en el SBC para poder verificar si se detecta el sensor. Para este propósito, ejecute el comando "sudo raspi-config", siga la secuencia Opciones de interfaz -> I2C -> Sí en el menú mostrado y reinicie el SBC para que los cambios sean efectivos.
   3. Verifique que se detecte el sensor Instalando el software i2c-tools en el SBC, y ejecutando el comando "sudo i2cdetect -y 1". Si es así, debería aparecer una cuadrícula que indique la posición donde se detecta el sensor.
   4. Instale las bibliotecas de software adecuadas para permitir que el SBC lea y envíe los datos proporcionados por el sensor. En particular, este experimento aprovecha las bibliotecas de Python RPi.bme280³² y paho-mqtt^33.
8. Utilizando la aplicación móvil del SUAV, despegue el vehículo aéreo que aloja el Punto de Acceso VNF,y colóquelo para proporcionar cobertura inalámbrica al SBC con el sensor.
   NOTA: El vuelo de los SUV con capacidad NFV es independiente del comportamiento operativo del servicio de red, que puede operar si los SUV están volando o en un estado de reposo para mitigar el consumo de batería. Por lo tanto, el paso 4.8 es opcional.
9. Conecte el SBC encargado de leer los datos recogidos por el sensor al punto de acceso inalámbrico Wi-Fi proporcionado por el Punto de Acceso VNF). Después de una conexión correcta, se habilitará una ruta de red inalámbrica desde el sensor hasta MQTT Gateway VNF.
10. Inicie la transmisión de datos detectados, ejecutando el comando "python3 /home/ubuntu/sensorDataTransmission.py -a " en el SBC que incorpora el sensor ( es la dirección IP obtenida en el paso 4.6.).
11. Acceda a la GUI web proporcionada por el servidor IoT VNF para verificar la recepción correcta en tiempo real de los datos detectados. Con ese fin, verifique la dirección IP del servidor IoT VNF con el comando "osm vnf-list" y escriba el siguiente Localizador uniforme de recursos (URL) en un navegador web: http://:3001, donde es la dirección IP del servidor IoT VNF. Luego, haga clic en el botón Recopilación de datos de sensores de la pestaña Inicio y verifique la actualización en tiempo real de los gráficos incluidos en el panel a medida que se reciben los datos.
    NOTA: Para poder acceder a la URL mencionada en el paso 4.12, el dispositivo con el navegador web que intenta llegar a ese recurso debe estar conectado al ecosistema NFV y tener conectividad IP con el servidor IoT VNF. El servicio VPN también se puede utilizar para este propósito.
12. Espere un período de tiempo adecuado para obtener resultados representativos de la ejecución del servicio de agricultura inteligente. A continuación, recopile los datos almacenados en el servidor de IoT VNF para su posterior análisis. Teniendo en cuenta que el sensor incluido en este experimento proporciona lecturas de temperatura, humedad y presión cada 5 segundos, el servicio en el experimento se ejecuta durante un período de 10 minutos, lo que resulta en 180 muestras de datos detectados (60 para cada tipo de valor meteorológico).
13. Acceda a la base de datos del servidor ioT VNF para recuperar los datos detectados para su posterior análisis. Para ello, ejecute el comando "id_database=$(sudo docker ps | grep 'influxdb:' | cut -d ' ' -f 1)" en el servidor IoT VNF, y luego "sudo docker exec -it $id_database bash"
14. Exporte los datos a un archivo de valores separados por comas (CSV), ejecutando el comando "influx -database 'mainflux' -execute "SELECT * FROM messages WHERE \"name\" = '' " -format csv > /tmp/.csv". Modifique el parámetro para seleccionar qué tipo de datos detectados se van a exportar con la "temperatura", "humedad" o "presión", y establezca el parameter para elegir un nombre para el archivo de salida que mantendrá los resultados.
15. Guarde los archivos de datos generados en el paso anterior para su posterior representación (consulte la sección Resultados representativos) y la verificación del correcto funcionamiento del servicio de agricultura inteligente.

Representative Results

Después de seguir cuidadosamente el protocolo para incorporar un nuevo sitio a la plataforma central y ejecutar un servicio de red para validar su funcionalidad adecuada, la Figura 6 muestra una captura de pantalla de la herramienta open-vpn-monitor. Se puede observar cómo el nuevo sitio está utilizando la VPN para todas sus comunicaciones, mostrando cómo sus comunicaciones siguen la VPN para permitir este intercambio de datos y, en consecuencia, la adición correcta del nuevo sitio al servicio VPN.

Como se muestra en la Figura 3,el servicio de red está entregando información desde un sensor ubicado en una infraestructura remota al servidor ubicado en el sitio central. Además, la Figura 7 muestra la implementación exitosa del servicio de red desde la GUI web de OSM, mostrando cómo se puede crear una instancia del experimento correctamente en la nueva infraestructura remota desde la pila MANO ubicada dentro del sitio central. Además, el tiempo requerido en el experimento para completar el despliegue del servicio es de alrededor de ocho minutos. Este valor, junto con el tiempo necesario para incorporar los descriptores de servicio en la plataforma de orquestación (unos 9 segundos, con 1,3 segundos por descriptor, considerando tanto el NS como cada descriptor VNF), permite satisfacer el Indicador Clave de Rendimiento (KPI) de 90 minutos para el tiempo de creación del servicio, tal y como indica la 5G Infrastructure Public Private Partnership³⁴. En este contexto, el trabajo presentado en Vidal et al.⁹ incluye un análisis en profundidad del tiempo de creación del servicio con múltiples sitios utilizando el protocolo presentado.

La Figura 8 muestra los datos recopilados del sensor, incluidos los valores de humedad, temperatura y presión, respectivamente. Estas muestras corresponden a todos los datos enviados desde el sensor a un servidor remoto ubicado en 5TONIC, donde estos valores se almacenan en una base de datos. Todos estos datos demuestran que la plataforma es capaz de desplegar servicios de red prácticos después de la inclusión de una nueva infraestructura, así como de habilitar correctamente las comunicaciones entre sitios.

Figura 1:Distribución del sitio de servicio VPN. Distribución del servicio VPN a través de la plataforma y su conectividad de enlace (todo a través de 5TONIC). Haga clic aquí para ver una versión más grande de esta figura.

Figura 2. Descripción general de la plataforma y el servicio VPN. Esta figura muestra todos los elementos de la plataforma: la ubicación central, junto con su infraestructura NFV, el servicio VPN y una nueva infraestructura agregada al sistema. También incluye las conexiones entre sus elementos. Haga clic aquí para ver una versión más grande de esta figura.

Figura 3: Descripción general del servicio de red. Representa los elementos involucrados en el servicio de red, su distribución y su conectividad lógica y de red. Haga clic aquí para ver una versión más grande de esta figura.

Figura 4:Flujos de trabajo de protocolo. Cada columna representa una sección del protocolo, donde se describe cada acción realizada, su conexión lógica entre ellas y el componente encargado de su ejecución. Haga clic aquí para ver una versión más grande de esta figura.

Figura 5: Esquema de configuración de pines. Diagrama que representa cómo realizar las conexiones físicas entre los pines de placa de los sensores y los pines GPIO del SBC que incorpora ese sensor. Haga clic aquí para ver una versión más grande de esta figura.

Figura 6:Instantánea de Monitor OpenVPN. La imagen muestra que la infraestructura agregada está conectada al servicio VPN, incluidos algunos de sus detalles sobre su conexión. Además, la figura también muestra conexiones adicionales pertenecientes a otras infraestructuras remotas. Haga clic aquí para ver una versión más grande de esta figura.

Figura 7:Estado de implementación de OSM NS. Interfaz gráfica OSM, que muestra la implementación exitosa del servicio de red de prueba en la infraestructura remota. Haga clic aquí para ver una versión más grande de esta figura.

Figura 8: Análisis representativo de los datos recogidos por el sensor. (A) Ilustración de los datos de temperatura recogidos periódicamente por el sensor cada 5 segundos. (B) Representación gráfica de los datos de humedad recogidos por el sensor cada 5 segundos. (C) Representación visual de los datos de presión recopilados por el sensor cada 5 segundos. Haga clic aquí para ver una versión más grande de esta figura.

Discussion

Uno de los aspectos más importantes del protocolo descrito anteriormente es su extraordinaria flexibilidad para incorporar nuevas infraestructuras computacionales a un ecosistema NFV, independientemente de su distribución en términos de ubicación geográfica (siempre y cuando el ancho de banda y la latencia de las comunicaciones de red con sitios remotos lo admitan). Esto es posible a través de una arquitectura de red superpuesta basada en VPN, que permite el establecimiento de un enlace virtual para conectar sitios remotos a las instalaciones centrales del ecosistema NFV. Este enfoque permite la provisión de un canal efectivo y seguro para soportar el NFV y las comunicaciones de datos entre los sitios de un ecosistema NFV, reduciendo la probabilidad de que partes externas accedan y/o modifiquen información confidencial sobre los procesos de orquestación de NFV y los datos de los servicios implementados. En este contexto, el protocolo también describe una metodología específica para compartir de forma segura las credenciales de VPN con los sitios externos que permitirán la integración de nuevas infraestructuras. El protocolo ha sido ejemplificado utilizando el ecosistema NFV puesto a disposición en 5TONIC por la Universidad Carlos III de Madrid, Telefónica e IMDEA Networks Institute, aunque es genérico para ser utilizado en otros entornos NFV que cumplan con los requisitos previos mencionados en el paso 1 de este protocolo.

Además, vale la pena enfatizar la utilización exclusiva de herramientas y software de código abierto para la implementación del protocolo. A pesar de las funcionalidades potencialmente beneficiosas que podrían ofrecer las diferentes soluciones propietarias (por ejemplo, Fortinet³⁵), el uso de desarrollos de código abierto ha facilitado la integración de todos los elementos abarcados por el protocolo debido a sus características inherentes, como la rentabilidad, un amplio soporte de software proporcionado por la comunidad de código abierto y un alto nivel de fiabilidad. solo por nombrar algunos de ellos. Además, la utilización de tecnologías de código abierto también puede promover sinergias entre componentes de naturaleza similar. Por ejemplo, para monitorear el estado de la conexión VPN para los clientes que usan la plataforma, el servicio VPN implementado en todo el protocolo podría confiar en la herramienta de monitoreo open-vpn³⁶ (una herramienta de monitoreo basada en Python capaz de interoperar con servidores OpenVPN).

Por otro lado, la especificación del protocolo considera la creación de instancias de servicios de red en diferentes sitios con fines de validación. En este sentido, es importante destacar que el despliegue de servicios en un sitio determinado está sujeto a la disponibilidad de recursos informáticos, de almacenamiento y de red en el sitio, así como de equipos especializados que podrían ser necesarios para realizar el despliegue (por ejemplo, SUAV habilitados para NFV). Esto no es una limitación del protocolo, y debe ser tenido en cuenta por las partes interesadas en reproducir el experimento descrito en este documento.

Además, cabe señalar que el tiempo necesario para llevar a cabo el despliegue de servicios de red depende en gran medida de varios factores, como la ruta de red entre el orquestador y los diferentes VIM, el rendimiento de las comunicaciones de datos entre el VIM y sus nodos computacionales administrados, y también en la naturaleza intrínseca de estos nodos computacionales (no solo por sus recursos informáticos disponibles, pero también las tecnologías incorporadas para llevar a cabo la virtualización de las funciones de red).

Por último, y dado el destacado rendimiento que esta plataforma y su servicio VPN tuvieron en los proyectos europeos y trabajos colaborativos donde se ha utilizado hasta ahora (por ejemplo, 5GINFIRE, 5GRANGE o 5GCity, mencionados en la introducción de este documento), se considerará como un elemento importante en proyectos europeos emergentes donde la Universidad Carlos III de Madrid, Participan Telefónica, e IMDEA Networks Institute, como el Laberinto Horizonte 2020, o proyectos nacionales, como 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/