Implementación automatizada de un servicio de telefonía de protocolo de Internet en vehículos aéreos no tripulados mediante la virtualización de funciones de red

Resumen

El objetivo del protocolo descrito es doble: configurar un entorno de virtualización de funciones de red utilizando vehículos aéreos no tripulados como entidades computacionales que proporcionan la estructura subyacente para ejecutar funciones de red virtualizadas y utilizar este entorno para apoyar el despliegue automatizado de un servicio funcional de telefonía de protocolo de Internet a través de los vehículos aéreos.

Resumen

El paradigma de virtualización de funciones de red (NFV) es una de las tecnologías habilitadoras clave en el desarrollo de la^5a generación de redes móviles. Esta tecnología tiene como objetivo disminuir la dependencia del hardware en la provisión de funciones y servicios de red mediante el uso de técnicas de virtualización que permiten la softwarización de esas funcionalidades a través de una capa de abstracción. En este contexto, existe un interés creciente en explorar el potencial de los vehículos aéreos no tripulados (UAV) para ofrecer una plataforma flexible capaz de permitir operaciones de NFV rentables en áreas geográficas delimitadas.

Para demostrar la viabilidad práctica de utilizar tecnologías NFV en plataformas UAV, se presenta un protocolo para establecer un entorno NFV funcional basado en tecnologías de código abierto, en el que un conjunto de pequeños UAV suministran los recursos computacionales que soportan la implementación de servicios de red moderadamente complejos. A continuación, el protocolo detalla los diferentes pasos necesarios para admitir la implementación automatizada de un servicio de telefonía de protocolo de Internet (IP) a través de una red de UAVs interconectados, aprovechando las capacidades del entorno NFV configurado. Los resultados de la experimentación demuestran el funcionamiento correcto del servicio después de su implementación. Aunque el protocolo se centra en un tipo específico de servicio de red (es decir, telefonía IP), los pasos descritos pueden servir como una guía general para implementar otro tipo de servicios de red. Por otro lado, la descripción del protocolo considera equipos y software concretos para configurar el entorno NFV (por ejemplo, ordenadores específicos de placa única y software de código abierto). La utilización de otras plataformas de hardware y software puede ser factible, aunque el aspecto de configuración específico del entorno NFV y la implementación del servicio puede presentar variaciones con respecto a las descritas en el protocolo.

Introducción

Uno de los objetivos más codiciados dentro de la nueva era de las comunicaciones móviles (más comúnmente conocida como la^generación móvil 5 o 5G) es poder proporcionar servicios de tecnología de la información robustos en situaciones en las que la infraestructura de telecomunicaciones primaria puede no estar disponible (por ejemplo, debido a una emergencia). En este contexto, los UAV están recibiendo una atención cada vez mayor de la comunidad investigadora debido a su versatilidad inherente. Hay numerosas obras que utilizan estos dispositivos como piedra angular para la prestación de una gran variedad de servicios. Por ejemplo, la literatura ha analizado la capacidad de estos dispositivos para construir una infraestructura de comunicación aérea para dar cabida a los servicios multimedia^1,2,3. Además, investigaciones previas han demostrado cómo la cooperación entre varios UAV puede ampliar la funcionalidad de diferentes servicios de comunicación como vigilancia^4,búsqueda colaborativa y rescate^5,6,7,8,o agronegocio^9.

Por otro lado, la tecnología NFV ha adquirido gran importancia dentro de los operadores de telecomunicaciones como uno de los habilitadores clave 5G. NFV representa un cambio paradigmático con respecto a la infraestructura de telecomunicaciones al aliviar la dependencia actual de los dispositivos de red en hardware especializado a través de la softwarization de las funcionalidades de la red. Esto permite una implementación flexible y ágil de nuevos tipos de servicios de comunicación. Para ello, el Instituto Europeo de Normas de Telecomunicaciones (ETSI) formó un grupo de especificaciones para definir el marco arquitectónico NFV¹⁰. Además, el ETSI actualmente aloja el grupo¹¹de Mano de código abierto (OSM), que se encarga de desarrollar una pila de software NFV Management and Orchestration (MANO) alineada con la definición del marco arquitectónico ETSI NFV.

Teniendo en cuenta todas las consideraciones antes mencionadas, la convergencia sinérgica entre los UAV y las tecnologías NFV se está estudiando actualmente en el desarrollo de nuevas aplicaciones y servicios de red. Así lo ilustran varios trabajos de investigación en la literatura que señalan las ventajas de este tipo de sistemas^14,15,16,identifican los retos de esta convergencia y sus aspectos faltantes, destacan futuras líneas de investigación sobre este tema^17,y presentan soluciones pioneras basadas en tecnologías de código abierto.

En particular, la integración de las tecnologías NFV en el ámbito UAV permite el despliegue rápido y flexible de servicios de red y aplicaciones sobre áreas geográficas delimitadas (por ejemplo, un servicio de telefonía IP). Siguiendo este enfoque, se pueden implementar varios UAV en una ubicación específica, transportando plataformas informáticas como carga útil (por ejemplo, computadoras de placa única de tamaño pequeño). Estas plataformas informáticas proporcionarían una infraestructura de red programable (es decir, una infraestructura NFV) sobre el área de implementación, soportando la creación de instancias de servicios de red y aplicaciones bajo el control de una plataforma MANO.

A pesar de las ventajas, la realización de esta vista presenta un conjunto de desafíos fundamentales que deben abordarse cuidadosamente, como la integración adecuada de estas plataformas de proceso como una infraestructura NFV, utilizando una pila de software NFV existente, para que un servicio de orquestación NFV pueda implementar funciones virtuales en los UAV; las limitaciones en términos de los recursos computacionales proporcionados por las plataformas de computación, ya que los UAV que los transportan pueden normalmente presentar limitaciones en términos de tamaño, peso y capacidad informática de los equipos de carga útil; la colocación adecuada de las funciones virtuales en los UAV (es decir, seleccionar al mejor candidato UAV para desplegar una función virtual en particular); el mantenimiento de las comunicaciones de control con los UAV con el fin de gestionar el ciclo de vida de los VMF a pesar de la disponibilidad potencialmente intermitente de las comunicaciones de red con ellos (por ejemplo, causada por la movilidad y las restricciones de la batería); el tiempo de funcionamiento limitado de los UAVs debido a su consumo de batería; y la migración de las funciones virtuales cuando un UAV necesita ser reemplazado debido a su agotamiento de la batería. Estos beneficios y desafíos se detallan en trabajos anteriores^18,19 que incluye el diseño de un sistema NFV capaz de soportar el despliegue automatizado de funciones y servicios de red en plataformas UAV, así como la validación de la viabilidad práctica de este diseño.

En este contexto, este documento se centra en describir un protocolo para permitir la implementación automatizada de servicios de red moderadamente complejos a través de una red de UAVs utilizando los estándares NFV y tecnologías de código abierto. Para ilustrar los diferentes pasos del protocolo, se presenta una reelaboración de un experimento presentado en Nogales et al.^19, que consiste en el despliegue de un servicio de telefonía IP. Para ayudar a la reproducibilidad de este trabajo, el vuelo real se considera opcional en el procedimiento presentado, y los resultados de rendimiento se obtienen con los dispositivos UAV en el suelo. Los lectores interesados deben ser capaces de replicar y validar la ejecución del protocolo, incluso en un entorno de laboratorio controlado.

El cuadro 1 ilustra el servicio de red diseñado para este procedimiento. Este servicio de red se construye como una composición de unidades de softwarization específicas (categorizadas dentro del paradigma NFV como Virtual Network Functions, o VNFs) y proporciona la funcionalidad de un servicio de telefonía IP a los usuarios cercanos a los UAV. El VNF que compone el servicio se define de la siguiente manera:

• Punto de acceso VNF (AP-VNF): Este VNF proporciona un Punto de acceso Wi-Fi al equipo del usuario final (es decir, teléfonos IP en este experimento).
• Servidor de telefonía IP VNF (IP-telefonía-servidor-VNF): Es responsable de administrar los mensajes de señalización de llamada que se intercambian entre los Teléfonos IP para establecer y terminar una llamada de voz.
• Sistema de nombres de dominio VNF (DNS-VNF): Este VNF proporciona un servicio de resolución de nombres, que normalmente se necesita en los servicios de telefonía IP.
• VNF del router de acceso (AR-VNF): proporciona las funcionalidades de ruteo de red, soportando el intercambio de tráfico (es decir, señalización de llamadas en este experimento) entre los Teléfonos IP y el dominio del operador de telecomunicaciones.
• Router principal VNF (CR-VNF): proporciona funcionalidades de enrutamiento de red en el dominio del operador de telecomunicaciones, ofreciendo acceso a servicios específicos del operador (es decir, el servidor de telefonía IP) y redes de datos externas.

Además, la Figura 1 presenta los dispositivos físicos utilizados para el experimento, cómo están interconectados y la asignación específica de VNF a los dispositivos.

Protocolo

1. Requisitos previos para el experimento

1. Instale la pila de software de administración y orquestación (MANO) proporcionada por el proyecto MANO de código abierto (OSM). Específicamente, este experimento utiliza OSM Release FOUR²⁰, que se puede ejecutar en un único equipo servidor o en una máquina virtual (VM) que cumple con los requisitos especificados por la comunidad OSM: Ubuntu 16.04 como sistema operativo (imagen variante de 64 bits), dos unidades de procesamiento central (CPU), 8 GB de memoria de acceso aleatorio (RAM), un disco de almacenamiento de 40 GB y una única interfaz de red con acceso a Internet. El procedimiento para instalar OSM Release FOUR junto con sus detalles técnicos están disponibles en la documentación en línea proporcionada por la comunidad OSM²¹.
2. Configure una plataforma de computación en la nube, proporcionando las funciones de un administrador de infraestructura virtual (VIM) compatible con OSM Release FOUR. Para este experimento, se utiliza la versión ocata²² de OpenStack, que se ejecuta en una máquina virtual con Ubuntu 16.04 como sistema operativo, cuatro CPU, 16 GB de RAM y 200 GB de disco de almacenamiento. En el experimento, el VIM administra una infraestructura NFV (NFVI) integrada por dos equipos de servidor de alto perfil, cada uno con Ubuntu 16.04 como sistema operativo, ocho CPU, 128 GB de RAM y 4 TB de disco de almacenamiento). Toda la información sobre cómo configurar una plataforma de computación en la nube se incluye en la guía de instalación incluida en la documentación de OpenStack²³. Esta plataforma en la nube se conoce como la plataforma en la nube principal.
3. Configurar una plataforma de computación en la nube adicional para los UAV se conoce como la plataforma en la nube de los UAV.
   1. Asegúrese de que esta plataforma cuenta con un VIM basado en la versión Ocata de OpenStack. En este caso, los recursos utilizados por la instalación de VIM son Ubuntu 16.04 como sistema operativo, dos CPU, 6 GB de RAM, 100 GB de disco de almacenamiento y un adaptador USB Wi-Fi externo.
   2. El NFVI integrado en esta plataforma en la nube consta de un único servidor de computación fijo (Ubuntu 16.04 como sistema operativo, ocho CPU, 8 GB de RAM, disco de almacenamiento de 128 GB y un adaptador USB Wi-Fi externo) y tres ordenadores de placa única (SBC). Estos últimos proporcionan una plataforma de hardware que se puede incorporar fácilmente en un UAV. Consulte la Sección 3 para ver el procedimiento para configurar una plataforma en la nube UAV con estos dispositivos como nodos de proceso.
4. Equipe cada SBC con un hardware de alimentación de batería conectado en la parte superior (HAT) para garantizar el funcionamiento de estas unidades incluso cuando están en movimiento, siendo transportados por un UAV.
   NOTA: El paso 1.5 es opcional porque la provisión del servicio de red en el experimento no depende de tener UAVs. Además, los SBCse se llevan como carga útil de los UAVs y no se necesitan otras conexiones adicionales (por ejemplo, Ethernet o USB), porque las comunicaciones de red necesarias para el correcto funcionamiento del servicio de telefonía IP son proporcionadas por los SBCs, a través de sus adaptadores Wi-Fi, y la fuente de alimentación es proporcionada por el HAT de fuente de alimentación mencionado en el paso 1.4.
5. Conecte cada SBC como la carga útil de un UAV a través de un accesorio de fijación. En este experimento, se eligieron tres UAV comerciales para transportar las unidades de cómputo ofrecidas por los SBC.
6. Seleccione dos teléfonos inalámbricos de voz sobre IP (VoIP) que admitan el estándar de comunicaciones inalámbricas IEEE 802.11b; este modelo proporciona comunicaciones inalámbricas a través de Wi-Fi. Como alternativa, la llamada de voz podría ser ejecutada usando aplicaciones de softphone tales como Linphone²⁴ o Jitsi^25.
7. Como requisito experimental, asegúrese de la disponibilidad de: a) las comunicaciones de capa 3 entre la pila de software OSM y cada uno de los VIM para permitir la implementación orquestada del servicio de red desarrollado para este experimento, b) comunicaciones de capa 3 entre el OSM y los VNF en cada plataforma en la nube para admitir los procedimientos de configuración de VNF, y c) las comunicaciones de capa 3 entre los VNF que se ejecutan en cada VIM para permitir el correcto funcionamiento del servicio de red.
8. Todo el contenido necesario para llevar a cabo el experimento se proporciona en el repositorio de experimentos público http://vm-images.netcom.it.uc3m.es/JoVE/.

2. Validar la funcionalidad de las unidades de softwarization a través de la emulación

NOTA: Para probar el funcionamiento adecuado del servicio de red del experimento (consulte la figura 1) en condiciones de implementación realistas, se utilizó una plataforma de emulación específica de un propósito basada en los contenedores Linux²⁶ y ns-3^27. Esta plataforma permite emular enlaces aéreos multisalto y definir las características de esos enlaces (por ejemplo, la longitud de los enlaces de comunicación inalámbrica, el patrón de pérdidas de paquetes de datos, la tecnología de radio utilizada en las comunicaciones inalámbricas, etc.). Así, esta sección del protocolo describe los pasos a seguir para verificar el funcionamiento apropiado del servicio de telefonía IP bajo condiciones realistas del link de comunicación inalámbrica a través de la plataforma de emulación.

1. Descargue la plataforma de emulación desde el repositorio de experimentos. La plataforma está disponible como una máquina virtual, denominada "uav-nfv-jove-experiment.qcow", compatible con la tecnología de virtualización KVM^28. Esta máquina contiene una plantilla creada previamente que emula el servicio de red y el escenario multi-UAV presentado en la Figura 1 y un usuario con privilegios de administrador capaces de ejecutar esa plantilla.
   NOTA: De forma predeterminada, los pasos siguientes se ejecutan automáticamente cuando se inicia la máquina virtual de la plataforma de emulación: a) el entorno virtual está configurado para habilitar la emulación de red (es decir, interfaces de red, puentes Linux^29); b) se crean los contenedores Linux que representan los diferentes componentes físicos del banco de pruebas (es decir, los SBC y el servidor de proceso fijo para la plataforma en la nube UAV y el servidor informático para la plataforma de nube principal); y c) las funciones proporcionadas por los diferentes VNF del servicio de telefonía IP (es decir, puntos de acceso, enrutadores, servicio DNS y servidor de telefonía IP) se implementan como contenedores Linux sobre sus correspondientes SBCs emulados y servidores informáticos.
2. Antes del proceso de validación, configure una red aérea de múltiples saltos emulada usando el simulador ns-3, para habilitar la Conectividad entre los diversos participantes de la red. Este procedimiento emulará las comunicaciones inalámbricas realistas que tienen lugar en el escenario descrito en la Figura 1 (es decir, la red ad hoc Wi-Fi, que permite el intercambio de datos entre los nodos de la plataforma en la nube UAV y las redes inalámbricas ofrecidas por los dos puntos de acceso Wi-Fi proporcionados en el servicio).
   1. Cree la red aérea de varios saltos. Para ello, ejecute el script multi-hop-aerial-net.sh (disponible en la máquina de la plataforma de emulación) utilizando el siguiente comando: sudo sh /home/jovevm/scripts/multi-hop-aerial-net.sh > multi-hop-aerial-net-trace.log 2>&1 &. Este comando representa el seguimiento de simulación en el archivo de registro especificado para habilitar la depuración en caso de errores.
   2. Compruebe si la red se ha creado correctamente. Con este fin, verifique si los contenedores De Linux "IP-phone-a" y "IP-phone-b" (ilustrado en el cuadro 1 como el equipo del usuario final que conecta con un AP-VNF) han obtenido una dirección IP a través del servicio DHCP, que es accesible solamente a través de la red aérea del multisalto. El estado del contenedor Linux ejecutado dentro de la máquina de emulación, así como sus direcciones IP, se puede comprobar mediante el comando lxc list.
3. Verifique la capacidad del servicio de red emulado para procesar los mensajes de señalización necesarios para configurar la llamada de telefonía IP. Para ello, los contenedores Linux "IP-phone-a" y "IP-phone-b" han instalado la herramienta "SIPp"³⁰. "SIPp" proporciona la funcionalidad para emular un teléfono del IP que crea los mensajes de señalización mencionados, enviarlos a un servidor de telefonía IP, y procesar la respuesta para verificar el funcionamiento correcto de este último.
   1. Ejecute el script test-signaling.sh en ambos contenedores, que ejecuta la herramienta "SIPp" para generar y enviar mensajes de señalización al IP-telephony-server-VNF.
   2. Compruebe la pantalla de escenario proporcionada por la ejecución del paso anterior. La recepción de la respuesta "200" muestra el funcionamiento adecuado del IP-telefonía-servidor-VNF.
4. Valide que el servicio de red puede procesar el tráfico de datos que se genera durante una llamada de telefonía IP. Para ello, la herramienta de programación de flujo "Trafic"³¹ se instala en los contenedores de Linux "IP-phone-a" y "IP-phone-b".
   1. Ejecute el siguiente comando para iniciar el agente de servidor de Trafic: lxc exec IP-phone-b sh called-party.sh.
   2. A continuación, ejecute el siguiente comando para iniciar el agente de cliente de Trafic y obtener las estadísticas de red: lxc exec IP-phone-a sh caller.sh. El tráfico de datos que emula una llamada de voz se termina después de 60 s. El script muestra un mensaje de confirmación y las métricas de rendimiento más significativas relacionadas con el tráfico de voz.
   3. Marque las métricas obtenidas y verifique que el servicio de telefonía IP pueda soportar eficazmente una conversación de voz interactiva. Para ello, consulte la información incluida en la sección sobre los resultados representativos.

3. Construcción de plataformas en la nube de UAVs

1. Seleccione el modelo de SBC que puede proporcionar el sustrato de virtualización para ejecutar VNF ligeros. Las especificaciones técnicas de los dispositivos SBC utilizados durante el experimento son: cuatro CPU, 1 GB de RAM y un disco de almacenamiento de 32 GB. Además, cada SBC tiene tres interfaces de red: una interfaz Ethernet, una interfaz Wi-Fi integrada y un adaptador USB Wi-Fi externo.
2. Prepare los SBCs para que se integren posteriormente en la plataforma en la nube de los UAV.
   1. Instale Ubuntu Mate³² 16.04.6 como sistema operativo, dado que los paquetes de instalación de OpenStack se incluyen en esta distribución de Linux.
   2. Instale y configure los paquetes necesarios como se indica en la documentación³³ de OpenStack para permitir que los SBC actúen como nodos de proceso de la plataforma en la nube UAV. Siguiendo la guía anterior, habilite la utilización de contenedores Linux en la configuración de los paquetes de OpenStack. La virtualización de contenedores se utiliza debido a las restricciones de recursos de los dispositivos que normalmente se pueden incorporar en UAVs de tamaño pequeño.
   3. En el SBC, descargue y ejecute el script rpi-networking-configuration.sh, disponible en el repositorio del experimento. Este script permite las comunicaciones inalámbricas de los SBCs, así como la configuración necesaria para permitir la creación de redes virtuales conectadas a las interfaces inalámbricas.
   4. Descargue y ejecute el script VIM-networking-configuration.sh, disponible en el repositorio de experimentos, en el host que ejecuta el VIM de la plataforma en la nube UAV. Este script supervisa la configuración de las comunicaciones inalámbricas del VIM para permitir el intercambio de información con los SBC.
      NOTA: Una vez que la red está bien configurada y el VIM tiene conectividad con los SBCs, el VIM los integra automáticamente en la plataforma en la nube UAV como unidades computacionales capaces de ejecutar VNF
3. Cree una zona de disponibilidad de OpenStack para cada uno de los SBC. Esto permitirá implementar cada uno de los VMF ligeros del experimento en una unidad UAV adecuada. Para ello, inicie sesión en la interfaz gráfica de usuario web proporcionada por el VIM con las credenciales de administrador, cree las zonas de disponibilidad en la pestaña Administrador > Sistema > Agregados de host y edite cada zona de disponibilidad para agregar el host adecuado (es decir, cada SBC integrado en la plataforma en la nube UAV).
4. Verifique la configuración correcta de la plataforma en la nube UAV. Para ello, acceda a la pestaña Administrador > Sistema > Información del sistema con el mismo inicio de sesión que en el paso anterior y haga clic en la sección Servicio de informática y agentes de red para comprobar que el estado de los elementos mostrados es "Alive" y "UP".

4. Configuración del experimento

1. Descargue las imágenes VNF que implementan los diferentes componentes del servicio de telefonía IP: el AP-VNF, el DNS-VNF, el IP-telephony-server-VNF, el AR-VNF y el CR-VNF. Estas imágenes se pueden descargar desde el repositorio del experimento.
2. Cargue las imágenes VNF en su VIM correspondiente (es decir, el AP-VNF y el DNS-VNF en el VIM de la plataforma en la nube UAV) y el VoIP-VNF en el VIM de la plataforma en la nube principal. Para ello, inicie sesión en la interfaz gráfica de usuario web proporcionada por cada VIM con las credenciales de administrador, haga clic en el botón Crear imagen de la pestaña Administrador > Sistema > Imágenes y cree una imagen utilizando el formulario mostrado y seleccionando la imagen adecuada. Este proceso se realiza en el VIM correspondiente para cada imagen que se ha descargado en el paso anterior.
3. Descargue los descriptores VNF (VNFD) del experimento desde el repositorio del experimento. Estos descriptores proporcionan las plantillas que describen los requisitos operativos de un VNF, así como las directivas de ubicación que indican la zona de disponibilidad encargada de hospedar el propio VNF. Puede encontrar más información sobre los descriptores NFV en el modelo de información de OSM³⁴.
4. Cargue los VNFD. Utilice un navegador web para acceder a la interfaz gráfica de usuario de OSM e inicie sesión con las credenciales de administrador. A continuación, arrastre y suelte los VNFD en la pestaña Paquetes VNF.
5. Descargue el descriptor de servicios de red (NSD) desde el repositorio de experimentos. Este descriptor es una plantilla que especifica los VNF que componen el servicio, así como cómo se interconectan esos VNF.
6. Cargue el NSD. Arrastre y suelte el NSD en la pestaña NS Packages de la interfaz gráfica de usuario OSM.
7. Mediante la interfaz gráfica de usuario de OSM, agregue una cuenta de VIM para el VIM de la plataforma en la nube UAV y para el VIM de la plataforma en la nube principal. Para ello, acceda a la pestaña Cuentas viM con las credenciales de administrador, haga clic en el botón + Nuevo VIM y complete el formulario mostrado con la información solicitada. Repita esta acción para ambos VIM.

5. Ejecución del experimento

1. Implemente el servicio de red. En la pestaña NS packages de la interfaz gráfica de usuario de OSM, haga clic en el botón Instantiate NS del NSD cargado en el paso 4.6. A continuación, rellene el formulario mostrado, indicando el VIM que se utilizará para desplegar cada VNF que compone el NS. Además, el OSM es responsable de procesar las políticas de colocación indicadas en los VNFD para especificar el VIM qué zona de disponibilidad (es decir, una unidad de proceso en nuestro banco de pruebas) se encarga de alojar cada VNF. Para este experimento, los VMF se colocan en las unidades de proceso como se muestra en la figura 1.
   NOTA: Como método alternativo, el OSM proporciona una interfaz de línea de comandos que permite la interacción directa del usuario. Un usuario que reproduzca este experimento puede utilizar esta interfaz de línea de comandos, en lugar de la interfaz gráfica, para ejecutar los diferentes pasos definidos en este protocolo, en particular los pasos relacionados con la incorporación de un VNF o un descriptor NS, así como la implementación de un servicio de red.
2. Espere hasta que la interfaz gráfica de usuario de OSM indique el éxito en la implementación del servicio de red.
   NOTA: El funcionamiento del servicio de red es totalmente independiente del vuelo de los UAV: El servicio de telefonía IP se puede proporcionar cuando los UAV vuelan o ahorran consumo de batería encaramado en una superficie. Por lo tanto, el paso 5.3 es opcional.
3. Quítate los UAVs. Inicie sesión en la aplicación móvil y controle el vuelo de cada UAV para mantenerlo estable en una altura intermedia y evitar las turbulencias causadas por la rotación de los motores cerca de una superficie.
4. Prepare cada uno de los teléfonos IP para llevar a cabo la llamada.
   1. Conecte un teléfono VoIP inalámbrico a cada uno de los puntos de acceso ofrecidos por el servicio de red. Para este propósito, especifique el SSID(identificadordel conjunto de servicios) en el menú > la lengueta de la Tecnología inalámbrica > SSID y elija el modo de infraestructura en el menú > la sección de la Tecnología inalámbrica > del modo de red. Finalmente, seleccione la configuración de red a través del Protocolo de configuración dinámica de host (DHCP) en la pestaña Menú > Configuración de red > Modo de red.
   2. Configure los parámetros del Session Initiation Protocol (SIP) para habilitar el intercambio apropiado de los mensajes de señalización con el servidor de telefonía IP. En este contexto, acceda a la pestaña Menú > Configuración sIP y especifique el nombre de host del servidor de telefonía IP VNF ("dronesVoIP.net") en las pestañas Registrar > Registrar IP y Servidor proxy > Proxy IP. Además, cree una cuenta de usuario que introduzca el nombre del usuario (por ejemplo, llamador-A) en las secciones Cuenta de usuario > Número de teléfono y Cuenta de usuario > Nombre de usuario.
   3. Cree una entrada en la agenda de uno de los Teléfonos IP que proporciona la información del usuario que se va a llamar. Para ello, seleccione la pestaña Menú > Agenda > Agregar entrada y rellene los parámetros solicitados que aparecen en la pantalla de la siguiente manera: Nombre para mostrar & llamador-B; Información del usuario: llamador-B; IP de host: dronesVoIP.net; Puerto 5060. Por último, seleccione la opción "Proxy" frente al P2P (peer-to-peer).
5. Inicie la llamada a la otra parte. Para hacerlo, seleccione la parte llamada usando el menú > la agenda > la opción de la búsqueda del teléfono del IP. A continuación, pulse el botón de llamada. Una vez que el otro teléfono del IP comienza a sonar, valide la llamada entrante con el botón de la llamada.

6. Procedimiento para obtener resultados experimentales

1. Conecte un ordenador portátil de la mercancía con uno de los puntos de acceso inalámbricos y funcione con la herramienta de línea de comandos ping a la dirección IP del teléfono conectado con el otro AP durante 180 s. La dirección IP se puede marcar en la opción del menú > de la información > de la dirección IP del teléfono del IP una vez que la conexión se establece con el AP. Salve las medidas del tiempo de ida y vuelta (RTT), reorientando la salida proporcionada por la herramienta ping en un archivo.
2. Ejecute la herramienta de línea de comandos tcpdump en uno de los VMF AP en ejecución para capturar el tráfico intercambiado durante la llamada IP. Guarde este tráfico en un archivo que habilite el indicador de escritura de la herramienta de línea de comandos en el momento de la ejecución y especifique el nombre del archivo.
3. Realice una nueva llamada de telefonía IP. Mantenga la llamada para el período de tiempo deseado (por ejemplo, 1 min). Entonces, termine la llamada, presionando el botón de colgar de uno de los Teléfonos IP.
4. Mantenga los archivos generados por las herramientas tcpdump y ping para su posterior procesamiento. Consulte Resultados representativos.

Resultados

Sobre la base de los datos obtenidos durante la ejecución del experimento, en el que se ejecuta una llamada VoIP real y siguiendo los pasos indicados por el protocolo para recopilar esta información, la Figura 2 representa la función de distribución acumulativa del retardo de extremo a extremo medido entre dos elementos de equipo de usuario final (es decir, un portátil de productos básicos y un teléfono IP). Este equipo de usuario representa dos dispositivos que están interconectados a través de los VMF AP del servicio de red desplegado. Más del 80% de las mediciones de retardo de extremo a extremo estaban por debajo de 60 ms, y ninguna de ellas era superior a 150 ms, lo que garantiza métricas de retardo adecuadas para la ejecución de una llamada de voz.

El cuadro 3 ilustra el intercambio de los mensajes de señalización DNS y del SORBO. Estos mensajes corresponden al registro de uno de los usuarios en el servidor de telefonía IP (es decir, el usuario cuyo teléfono IP está conectado al AP VNF donde se está ejecutando la herramienta"tcpdump"y al establecimiento de la llamada de voz.

Finalmente, el cuadro 4 y el cuadro 5 muestran el tráfico de datos capturado durante la llamada. En particular, el primero representa la secuencia constante de los paquetes de voz transmitidos y recibidos por uno de los teléfonos inalámbricos durante la llamada, mientras que el segundo ilustra el jitter en la dirección delantera con un valor promedio inferior a 1 ms.

Los resultados obtenidos en el experimento para las cifras de retraso (retraso de extremo a extremo y fluctuación) satisfacen las recomendaciones especificadas por la Unión Internacional de Telecomunicaciones - Sector de Normalización de las Telecomunicaciones (UIT-T)³⁵. En consecuencia, la llamada de voz progresó sin fallos y buena calidad de sonido. Este experimento validó la viabilidad práctica de utilizar tecnologías NFV y UAVs para implementar un servicio de telefonía IP funcional.

Figura 1: Descripción general del servicio de red, que representa los VMF, las entidades en las que se ejecutan y las redes virtuales necesarias para la prestación del servicio de telefonía IP. Haga clic aquí para ver una versión más grande de esta figura.

Figura 2: Retardo de extremo a extremo. Representación del retardo de extremo a extremo ofrecido al equipo del usuario final conectado con los VMF AP. Para ello, la función de distribución acumulativa del retardo de extremo a extremo se ha calculado a partir de las muestras de RTT medidas obtenidas con la herramienta de línea de comandos "ping". Haga clic aquí para ver una versión más grande de esta figura.

Figura 3: Mensajes de registro de usuarios y señalización de llamadas. Ilustración del tráfico de señalización (DNS y SIP) intercambiado para registrar a un usuario en el servidor de telefonía IP y para crear y terminar la sesión multimedia que soporta la ejecución de la llamada de voz. Haga clic aquí para ver una versión más grande de esta figura.

Figura 4: Flujo de paquetes de voz. Representación del tráfico de voz intercambiado durante la llamada, medido en uno de los VMF AP. (Abreviaturas: RX - recibir, RX - transmitir, RTP - protocolo de transporte en tiempo real). Haga clic aquí para ver una versión más grande de esta figura.

Figura 5: Evolución del jitter de la red durante la llamada. Representación del jitter experimentado por los paquetes de voz transmitidos en la dirección de avance de un teléfono al otro. Haga clic aquí para ver una versión más grande de esta figura.

Discusión

Uno de los aspectos más importantes de este experimento es el uso de tecnologías de virtualización y estándares NFV con plataformas UAV. NFV presenta un nuevo paradigma con el objetivo de desacoplar la dependencia de hardware de las funcionalidades de red, permitiendo así el suministro de estas funcionalidades a través de la softwarización. En consecuencia, el experimento no depende del uso del equipo de hardware especificado en el protocolo. Alternativamente, se pueden seleccionar diferentes modelos de computadoras de placa única, siempre y cuando estén en línea con las dimensiones y la capacidad de transporte de los UAVs y admitan contenedores Linux.

A pesar de esta flexibilidad en términos de selección de hardware, todo el contenido proporcionado para la reproducibilidad del experimento está orientado hacia el uso de tecnologías de código abierto. En este contexto, los aspectos de configuración y las herramientas de software están condicionados al uso de Linux como sistema operativo.

Por otro lado, el experimento considera la interoperación de dos plataformas computacionales diferentes (es decir, la plataforma en la nube UAV y la plataforma de nube principal) para proporcionar un servicio de red moderadamente complejo. Sin embargo, esto no es estrictamente necesario, y el protocolo podría seguirse para admitir escenarios en los que solo está implicada la plataforma en la nube UAV.

Además, la solución presentada podría utilizarse potencialmente en otros entornos, donde las plataformas de hardware con recursos limitados podrían estar disponibles con la capacidad necesaria para ejecutar contenedores de virtualización (por ejemplo, el Internet de las cosas o IoT, entornos). En cualquier caso, la aplicabilidad de esta solución a diferentes entornos y sus posibles adaptaciones requerirá un estudio cuidadoso caso por caso.

Por último, cabe señalar que los resultados presentados se han obtenido en un entorno de laboratorio y con los dispositivos UAV conectados a tierra o siguiendo un plan de vuelo limitado y bien definido. Otros escenarios que implican despliegues al aire libre pueden introducir condiciones que afectan a la estabilidad del vuelo de los UAV y, por lo tanto, al rendimiento del servicio de telefonía IP.

Materiales

Lista de materiales utilizados en este artículo

Nombre	Empresa	Número de catálogo	Comentarios
AR. Drone 2.0 - Edición Elite	Parrot		utilizado en el experimento para transportar los RPis y, por lo tanto, proporcionar movilidad a las unidades de cómputo de la plataforma en la nube de UAV.
Bebop 2	Parrot		UAV utilizado en el experimento para transportar los RPis y, por lo tanto, proporcionar movilidad a las unidades de cómputo de la plataforma en la nube de UAV.
Servidor comercial Intel Core Mini-ITX Computer	Logic Suppy		Computer que aloja el nodo controlador OpenStack (que se ejecuta como una máquina virtual) de la plataforma en la nube UAV del experimento. Además, otra unidad de este equipo (junto con el RPis) conforma los recursos computacionales de la plataforma en la nube UAV.
Contenedores Linux (LXC)	Canonical Ltd.		(Software) Tecnología de virtualización que permite el suministro de las funciones de red virtual detalladas en el experimento. Código fuente disponible en línea: https://linuxcontainers.org
Lithium Battery Pack Expansion Board. Modelo KY68C-UK	Kuman		Fuente de alimentación a batería HAT (Hardware Attached on Top) para las unidades de cálculo de la plataforma en la nube UAV (es decir, la Raspberry Pis). Además, este equipo abarca la carcasa utilizada para conectar las unidades de cómputo (es decir, los Raspberry PI o RPis) a los UAV.
MacBook Pro	Apple		Commodity laptop utilizada durante el experimento para obtener y recopilar los resultados descritos en el manuscrito.
ns-3 Simulador de red	nsnam		(Software) Un simulador de red de evento discreto que proporciona el sustrato de comunicación subyacente a la estación de emulación explicado en la sección "Protocolo" (más específicamente en el paso "2. Validar la funcionalidad de las unidades de softwarization vía Emulación"). Código fuente disponible en línea: https://www.nsnam.org
Open Source MANO (OSM) - Release FOUR	ETSI OSM - Open source community		(Software) Management and Orchestration (MANO) stack de software del sistema NFV configurado en el experimento. Código fuente disponible en línea: https://osm.etsi.org/wikipub/index.php/OSM_Release_FOUR
OpenStack - Release Ocata	OpenStack - Comunidad		abierto (Software) Software de código abierto utilizado para configurar tanto la plataforma de nube UAV como la nube central dentro del experimento. Código fuente disponible en línea: https://docs.openstack.org/ocata/install-guide-ubuntu
Ping	Herramienta		(Software) Una herramienta de prueba de código abierto, que verifica la conectividad entre dos dispositivos conectados a través de una red de comunicaciones. Además, esta herramienta permite evaluar el rendimiento de la red, ya que calcula el tiempo de ida y vuelta (es decir, el tiempo que se tarda en enviar y recibir un paquete de datos de la red). Código fuente disponible en línea: https://packages.debian.org/es/sid/iputils-ping
Power Edge R430	Dell		Servidor informático de alto perfil que proporciona la capacidad de cálculo dentro de la plataforma central en la nube presentada en el experimento.
Power Edge R630	Dell		Equipo utilizado para alojar la máquina virtual (VM) encargada de ejecutar la pila MANO. Además, el nodo de controlador de OpenStack también se ejecuta como una máquina virtual en este dispositivo. Tenga en cuenta que el uso de este dispositivo no es estrictamente necesario. Las operaciones llevadas a cabo por este dispositivo podrían ser realizadas por un equipo de menor rendimiento debido a las especificaciones de recursos no altas de las VM mencionadas anteriormente.
Prestige 2000W	ZyXEL		Voice over IP, compatible con el estándar de comunicaciones inalámbricas IEEE 802.11b. Este dispositivo se utiliza para llevar a cabo la llamada VoIP a través del servicio de red alojado por la plataforma descrita para la ejecución del experimento.
Frambuesa PI. Modelo 3b	Raspberry Pi Foundation		Modelo seleccionado de computadora de placa única (SBC) utilizado para proporcionar la capacidad computacional a la plataforma en la nube UAV del experimento.
	código abierto	SIPp	(Software) Una herramienta de prueba de código abierto, que genera tráfico de protocolo SIP. Esta herramienta permite verificar el correcto soporte del tráfico de señalización requerido en un servicio de telefonía IP como el desplegado en el experimento. Código fuente disponible en línea: http://sipp.sourceforge.net
Tcpdump	Open source tool		(Software) Una herramienta de código abierto que permite la captura y el análisis del tráfico de red. Código fuente disponible en línea: https://www.tcpdump.org
Trafic		de código abierto	(Software) Un programador de flujo de fuente abierta que se utiliza para validar la capacidad del servicio de red desplegado para procesar el tráfico de datos generado durante una llamada de telefonía IP. El código fuente está disponible en línea en: https://github.com/5GinFIRE/trafic