JoVE Journal > Engineering
Summary
Abstract
Introduction
Protocol
Results
Discussion
Disclosures
Acknowledgements
Materials
References
español

Automatically Generated
Please note that all translations are automatically generated. Click here for the English version.
Engineering

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

Published: November 26, 2019
doi:
10.3791/60425
, , , , ,
1Department of Telematic Engineering,Universidad Carlos III de Madrid, 2IMDEA Networks Institute

Summary

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.

Abstract

El paradigma de virtualización de funciones de red (NFV) es una de las tecnologías habilitadoras clave en el desarrollo de la5a 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.

Introduction

Uno de los objetivos más codiciados dentro de la nueva era de las comunicaciones móviles (más comúnmente conocida como lageneració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 multimedia1,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 vigilancia4,búsqueda colaborativa y rescate5,6,7,8,o agronegocio9.

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 NFV10. Además, el ETSI actualmente aloja el grupo11de 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 sistemas14,15,16,identifican los retos de esta convergencia y sus aspectos faltantes, destacan futuras líneas de investigación sobre este tema17,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 anteriores18,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.

Protocol

1. Requisitos previos para el experimento 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 FOUR20, 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 OSM21. 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 ocata22 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 OpenStack23. Esta plataforma en la nube se conoce como la plataforma en la nube principal. Configurar una plataforma de computación en la nube adicional para los UAV se conoce como la plataforma en la nube de los UAV. 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. 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. 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. 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. 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 Linphone24 o Jitsi25. 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. 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 Linux26 y ns-327. 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. 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 KVM28. 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 Linux29); 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. 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). 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. 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. 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”30. “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. 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. 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. 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”31 se instala en los contenedores de Linux “IP-phone-a” y “IP-phone-b”. Ejecute el siguiente comando para iniciar el agente de servidor de Trafic: lxc exec IP-phone-b sh called-party.sh. 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. 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 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. Prepare los SBCs para que se integren posteriormente en la plataforma en la nube de los UAV. Instale Ubuntu Mate32 16.04.6 como sistema operativo, dado que los paquetes de instalación de OpenStack se incluyen en esta distribución de Linux. Instale y configure los paquetes necesarios como se indica en la documentación33 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. 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. 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 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). 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 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. 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. 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 OSM34. 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. 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. Cargue el NSD. Arrastre y suelte el NSD en la pestaña NS Packages de la interfaz gráfica de usuario OSM. 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 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. 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. 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. Prepare cada uno de los teléfonos IP para llevar a cabo la llamada. 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. 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. 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). 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 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. 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. 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. Mantenga los archivos generados por las herramientas tcpdump y ping para su posterior procesamiento. Consulte Resultados representativos.

Representative Results

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)35. 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.

Discussion

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.

Disclosures

The authors have nothing to disclose.

Acknowledgements

Este trabajo fue apoyado parcialmente por el proyecto europeo H2020 5GRANGE (acuerdo de subvención 777137), y por el proyecto 5GCIty (TEC2016-76795-C6-3-R) financiado por el Ministerio de Economía y Competitividad de España. La obra de Luis F. González fue apoyada parcialmente por el proyecto europeo H2020 5GinFIRE (acuerdo de subvención 732497).

Materials

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

References

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

Tags

Automated DeploymentIP TelephonyUnmanned Aerial VehiclesNetwork Functions Virtualization5GVNFNSDOSMVIM

Play Video
PDF
DOI
DOWNLOAD MATERIALS LIST
Cite This Article
Nogales, B., Vidal, I., Sanchez-Aguero, V., Valera, F., Gonzalez, L. F., Azcorra, A. Automated Deployment of an Internet Protocol Telephony Service on Unmanned Aerial Vehicles Using Network Functions Virtualization. J. Vis. Exp. (153), e60425, doi:10.3791/60425 (2019).
Download Citation
Reprints and Permissions

View Video

✖

To prove you're not a robot, please enter the text in the image below

CAPTCHA Image
Play CAPTCHA Audio
Refresh Image