JoVE Journal > Engineering
Summary
Abstract
Introduction
Protocol
Results
Discussion
Disclosures
Acknowledgements
Materials
References
português

Automatically Generated
Engineering

Implantação automatizada de um serviço de telefonia de protocolo de Internet em veículos aéreos não tripulados usando a virtualização das funções de rede

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

Summary

O objetivo do protocolo descrito é duplo: configurar uma rede de funções ambiente de virtualização usando veículos aéreos não tripulados como entidades computacionais que fornecem a estrutura subjacente para executar funções de rede virtualizadae e usar este ambiente para apoiar a implantação automatizada de um serviço de telefonia de protocolo de internet funcional sobre os veículos aéreos.

Abstract

O paradigma de Virtualização da Função de Rede (NFV) é uma das principais tecnologias facilitadoras no desenvolvimento da5ª geração de redes móveis. Esta tecnologia visa diminuir a dependência de hardware na prestação de funções e serviços de rede usando técnicas de virtualização que permitem a softwarization dessas funcionalidades sobre uma camada de abstração. Neste contexto, há um interesse crescente em explorar o potencial de veículos aéreos não tripulados (VANTs) para oferecer uma plataforma flexível capaz de permitir operações de NFV econômicas em áreas geográficas delimitadas.

Para demonstrar a viabilidade prática da utilização de tecnologias NFV em plataformas uav, um protocolo é apresentado para criar um ambiente nfv funcional baseado em tecnologias de código aberto, em que um conjunto de pequenos VANTs fornecer os recursos computacionais que suportam implantação de serviços de rede moderadamente complexos. Em seguida, o protocolo detalha as diferentes etapas necessárias para apoiar a implantação automatizada de um serviço de telefonia de protocolo de internet (IP) através de uma rede de VANTs interconectados, aproveitando as capacidades do ambiente de NFV configurado. Os resultados da experimentação demonstram o bom funcionamento do serviço após sua implantação. Embora o protocolo se concentre em um tipo específico de serviço de rede (ou seja, telefonia IP), as etapas descritas podem servir como um guia geral para implantar outros tipos de serviços de rede. Por outro lado, a descrição do protocolo considera equipamentos e softwares de concreto para configurar o ambiente NFV (por exemplo, computadores específicos de placa única e software de código aberto). A utilização de outras plataformas de hardware e software pode ser viável, embora o aspecto de configuração específico do ambiente NFV e a implantação do serviço possam apresentar variações em relação às descritas no protocolo.

Introduction

Um dos objetivos mais cobiçados dentro da nova era das comunicações móveis (mais comumente conhecida como a5ª geração móvel ou 5G) é ser capaz de fornecer serviços robustos de tecnologia da informação em situações em que a infraestrutura primária de telecomunicações pode não estar disponível (por exemplo, devido a uma emergência). Neste contexto, os VANTs estão recebendo cada vez mais atenção da comunidade de pesquisa devido à sua versatilidade inerente. Existem inúmeros trabalhos que usam esses dispositivos como uma pedra angular para a prestação de uma grande variedade de serviços. Por exemplo, a literatura analisou a capacidade desses dispositivos de construir uma infraestrutura de comunicação aérea para acomodar os serviços multimídia1,2,3. Além disso, pesquisas anteriores mostraram como a cooperação entre vários VANTs pode ampliar a funcionalidade de diferentes serviços de comunicação, como vigilância4,busca colaborativa e resgate5,6,7,8,ou agronegócio9.

Por outro lado, a tecnologia NFV adquiriu grande importância dentro das operadoras de telecomunicações como um dos principais facilitadores 5G. A NFV representa uma mudança paradigmática em relação à infraestrutura de telecomunicações, aluviando a dependência atual de aparelhos de rede em hardware especializado por meio da softwarization das funcionalidades da rede. Isso permite uma implantação flexível e ágil de novos tipos de serviços de comunicação. Para este efeito, o European Telecommunications Standards Institute (ETSI) formou um grupo de especificações para definir o quadro arquitectónico NFV10. Além disso, o ETSI atualmente hospeda o open source mano (OSM) grupo11, que é responsável pelo desenvolvimento de uma gestão NFV e orquestração (MANO) pilha de software alinhado com a definição do ETSI NFV estrutura arquitetônica.

Dadas todas as considerações acima mencionadas, a convergência sinérgica entre VANTs e tecnologias NFV está sendo estudada no desenvolvimento de novas aplicações e serviços de rede. Isso é ilustrado por diversas obras de pesquisa na literatura que apontam as vantagens desses tipos de sistemas14,15,16,identificam os desafios dessa convergência e seus aspectos ausentes, destacam futuras linhas de pesquisa sobre este tema17,e apresentam soluções pioneiras baseadas em tecnologias de código aberto.

Em particular, a integração das tecnologias NFV na arena uav permite a implantação rápida e flexível de serviços de rede e aplicações em áreas geográficas delimitadas (por exemplo, um serviço de telefonia IP). Seguindo essa abordagem, vários VANTs podem ser implantados em um local específico, transportando plataformas de computação como carga útil (por exemplo, computadores de placa único de pequeno tamanho). Essas plataformas de computação forneceriam uma infraestrutura de rede programável (ou seja, uma infraestrutura nfv) sobre a área de implantação, suportando a instantiamento de serviços de rede e aplicativos o controle de uma plataforma MANO.

Não obstante os benefícios, a realização dessa visão apresenta um conjunto de desafios fundamentais que precisam ser cuidadosamente abordados, como a integração apropriada dessas plataformas de computação como uma infraestrutura nfv, usando uma pilha de software NFV existente, para que um serviço de orquestração NFV possa implantar funções virtuais nos Vants; as restrições em termos dos recursos computacionais fornecidos pelas plataformas de computação, uma vez que os VANTs que as transportam normalmente podem apresentar limitações em termos de tamanho, peso e capacidade de computação de equipamentos de carga útil; a colocação adequada das funções virtuais nos Vants (ou seja, selecionando o melhor candidato a Vants para implantar uma função virtual específica); a manutenção das comunicações de controle com os VANTs, a fim de gerenciar o ciclo de vida dos VNFs, apesar da disponibilidade potencialmente intermitente de comunicações de rede com eles (por exemplo, causada por restrições de mobilidade e bateria); o tempo de funcionamento limitado dos VANTs devido ao consumo de bateria; e a migração das funções virtuais quando um Vant precisa ser substituído devido à exaustão da bateria. Esses benefícios e desafios são detalhados em trabalhos anteriores18,19 que incluem o projeto de um sistema NFV capaz de suportar a implantação automatizada de funções e serviços de rede em plataformas uav, bem como a validação da viabilidade prática deste projeto.

Neste contexto, este artigo se concentra na descrição de um protocolo para permitir a implantação automatizada de serviços de rede moderadamente complexos através de uma rede de VANTs usando os padrões NFV e tecnologias de código aberto. Para ilustrar as diferentes etapas do protocolo, é apresentada uma reelaboração de um experimento apresentado em Nogales et al.19, consistindo na implantação de um serviço de telefonia IP. Para auxiliar a reprodutibilidade deste trabalho, o voo real é considerado opcional no procedimento apresentado, e os resultados de desempenho são obtidos com os dispositivos UAV no solo. Os leitores interessados devem ser capazes de replicar e validar a execução do protocolo, mesmo em um ambiente de laboratório controlado.

A Figura 1 ilustra o serviço de rede projetado para este procedimento. Este serviço de rede é construído como uma composição de unidades específicas de softwarization (categorizadas dentro do paradigma NFV como Funções de Rede Virtual, ou VNFs) e fornece a funcionalidade de um serviço de telefonia IP para usuários nas proximidades dos VANTs. O VNF compondo o serviço são definidos da seguinte forma:

  • Access Point VNF (AP-VNF): Este VNF fornece um ponto de acesso Wi-Fi para equipamentos de usuário final (ou seja, telefones IP neste experimento).
  • Servidor de telefonia IP VNF (IP-telefonia-servidor-VNF): É responsável por gerenciar as mensagens de sinalização de chamada que são trocadas entre telefones IP para estabelecer e encerrar uma chamada de voz.
  • Sistema de Nomes de Domínio VNF (DNS-VNF): Este VNF fornece um serviço de resolução de nomes, que normalmente é necessário em serviços de telefonia IP.
  • O roteador de acesso VNF (AR-VNF): fornece funcionalidades de roteamento de rede, apoiando a troca de tráfego (ou seja, sinalização de chamadas neste experimento) entre os telefones IP e o domínio da operadora de telecomunicações.
  • O roteador principal VNF (CR-VNF): fornece funcionalidades de roteamento de rede no domínio da operadora de telecomunicações, oferecendo acesso a serviços específicos do operador (ou seja, o servidor de telefonia IP) e redes de dados externas.

Além disso, a Figura 1 apresenta os dispositivos físicos usados para o experimento, como eles estão interligados e a alocação específica de VNFs para dispositivos.

Protocol

1. Requisitos anteriores para o experimento Instale a pilha de software de Gestão e Orquestração (MANO) fornecida pelo projeto Open Source MANO (OSM). Especificamente, este experimento usa o LANÇAMENTO DE OSM QUATRO20, que pode ser executado em um único computador de servidor ou em uma Máquina Virtual (VM) cumprindo os requisitos especificados pela comunidade OSM: Ubuntu 16.04 como o sistema operacional (imagem variante de 64 bits), duas unidades de processamento central (CPUs), memória de acesso aleatório de 8 GB (RAM), um disco de armazenamento de 40 GB e uma única interface de rede com acesso à Internet. O procedimento para instalar a liberação quatro do OSM junto com seus detalhes técnicos está disponível na documentação em linha fornecida pela comunidade21do OSM. Configure uma plataforma de computação em nuvem, fornecendo as funções de um gerente de infraestrutura virtual (VIM) compatível com o OSM Release FOUR. Para este experimento, o lançamento do OpenStack Ocata22 é usado, rodando em um VM com Ubuntu 16.04 como o sistema operacional, quatro CPUs, 16 GB DE RAM e 200 GB de disco de armazenamento. No experimento, o VIM gerencia uma infraestrutura NFV (NFVI) integrada por dois computadores de servidor de alto perfil, cada um com Ubuntu 16,04 como sistema operacional, oito CPUs, 128 GB RAM e disco de armazenamento de 4 TB). Todas as informações sobre como configurar uma plataforma de computação em nuvem estão incluídas no guia de instalação incluído na documentaçãoopenstack 23. Esta plataforma de nuvem é referida como a plataforma de nuvem principal. A configuração de uma plataforma adicional de computação em nuvem para os VANTs é referida como a plataforma de nuvem dos Vants. Certifique-se de que esta plataforma possui um VIM com base no lançamento do OpenStack Ocata. Neste caso, os recursos utilizados pela instalação vim são Ubuntu 16.04 como sistema operacional, duas CPUs, 6 GB RAM, disco de armazenamento de 100 GB e um adaptador USB Wi-Fi externo. O NFVI integrado nesta plataforma de nuvem consiste em um único servidor de computação fixa (Ubuntu 16.04 como sistema operacional, oito CPUs, 8 GB RAM, disco de armazenamento de 128 GB e um adaptador USB Wi-Fi externo) e três computadores de placa individuais (SBCs). Este último fornece uma plataforma de hardware que pode ser facilmente a bordo em um Vant. Veja a Seção 3 para o procedimento configurar uma plataforma de nuvem de Vants com esses dispositivos como nós de computação. Equipar cada SBC com um hardware de fornecimento de bateria-alimentação anexado em cima (HAT) para garantir o funcionamento dessas unidades, mesmo quando eles estão em movimento, sendo transportado por um Vant.NOTA: Passo 1.5 é opcional porque a prestação do serviço de rede no experimento não depende de ter VANTs. Além disso, os SBCs são transportados como a carga útil dos VANTs e sem outras conexões adicionais (por exemplo, Ethernet ou USB) são necessários, porque as comunicações de rede necessárias para a operação adequada do serviço de telefonia IP são fornecidas pelos SBCs, através de seus adaptadores Wi-Fi, e o fornecimento de energia é fornecido pelo CHAPÉU de fornecimento de energia mencionado na etapa 1.4. Anexar cada SBC como a carga útil de um Vant através de um acessório de fixação. Neste experimento, três VANTs comerciais foram escolhidos para transportar as unidades de computação oferecidas pelos SBCs. Selecione dois telefones sem fio de voz sobre IP (VoIP) que suportam o padrão de comunicações sem fio IEEE 802.11b; este modelo fornece comunicações sem fio via Wi-Fi. Como alternativa, a chamada de voz pode ser executada usando aplicativos de telefone sofrusado, como Linphone24 ou Jitsi25. Como requisito experimental, certifique-se da disponibilidade de: a) comunicações camada-3 entre a pilha de software OSM e cada um dos VIMs para permitir a implantação orquestrada do serviço de rede desenvolvido para este experimento, b) comunicações camada-3 entre o OSM e os VNFs em cada plataforma de nuvem para suportar os procedimentos de configuração vnf, e c) a camada-3 comunicações entre os VNFs rodando em cada VIM para permitir o bom funcionamento do serviço de rede. Todo o conteúdo necessário para realizar o experimento é fornecido no repositório de experimentos públicos http://vm-images.netcom.it.uc3m.es/JoVE/. 2. Validando a funcionalidade das unidades de softwarization via emulação NOTA: Para provar o funcionamento adequado do serviço de rede do experimento (ver Figura 1)condições realistas de implantação, uma plataforma de emulação específica com base nos contêineres Linux26 e ns-327 foi usada. Esta plataforma permite emular links aéreos multi-hop e definir as características desses links (por exemplo, comprimento dos links de comunicação sem fio, padrão de perdas de pacotes de dados, a tecnologia de rádio usada nas comunicações sem fio, etc.). Assim, esta seção do protocolo descreve as etapas a serem seguidas para verificar o funcionamento adequado do serviço de telefonia IP condições realistas de ligação de comunicação sem fio através da plataforma de emulação. Baixe a plataforma de emulação do repositório do experimento. A plataforma está disponível como uma máquina virtual, chamada “uav-nfv-jove-experiment.qcow”, compatível com a tecnologia de virtualização KVM28. Esta máquina contém um modelo pré-criado que emula o serviço de rede e o cenário multi-UAV apresentado na Figura 1 e um usuário com privilégios de administrador capazes de executar esse modelo.NOTA: Por padrão, as seguintes etapas são executadas automaticamente quando a máquina virtual da plataforma de emulação é iniciada: a) o ambiente virtual é configurado para habilitar a emulação da rede (ou seja, interfaces de rede, pontes Linux29); b) os Recipientes Linux que representam os diferentes componentes físicos do testbed (ou seja, os SBCs e o servidor de computação fixa para a plataforma de nuvem uav e o servidor de computação para a plataforma de nuvem principal) são criados; e c) as funções fornecidas pelos diferentes VNFs do serviço de telefonia IP (ou seja, pontos de acesso, roteadores, dns servem e servidor de telefonia IP) são implantadas como Recipientes Linux sobre seus Correspondentes SBCs emulados e servidores de computação. Antes do processo de validação, configure uma rede aérea multilés emulada usando o simulador ns-3, a fim de viabilizar a conectividade entre os diferentes participantes da rede. Este procedimento irá emular as comunicações sem fio realistas que ocorrem no cenário descrito na Figura 1 (ou seja, a rede Wi-Fi ad-hoc, que permite a troca de dados entre os nós da plataforma de nuvem UAV e as redes sem fio oferecidas pelos dois pontos de acesso Wi-Fi fornecidos no serviço). Crie a rede aérea multi-hop. Para tanto, execute o roteiro multi-hop-aerial-net.sh (disponível dentro da máquina de plataforma de emulação) usando o seguinte comando: sudo sh /home/jovevm/scripts/multi-hop-aerial-net.sh > multi-hop-aerial-net-trace.log 2>&1 &. Este comando retrata o traço de simulação no arquivo de registro especificado para permitir a depuração em caso de erros. Verifique se a rede foi criada com sucesso. Para isso, verifique se os Contêineres Linux “IP-phone-a” e “IP-phone-b” (ilustrado na Figura 1 como o equipamento do usuário final que se conecta a um AP-VNF) obtiveram um endereço IP através do serviço DHCP, que só é acessível através da rede aérea multilértica. O status do contêiner Linux executado dentro da máquina de emulação, bem como seus endereços IP, pode ser verificado usando a lista de comando lxc. Verifique a capacidade do serviço de rede emulado para processar as mensagens de sinalização necessárias para configurar a chamada de telefonia IP. Para isso, tanto os contêineres Linux “IP-phone-a” quanto “IP-phone-b” instalaram a ferramenta “SIPp”30. “SIPp” fornece a funcionalidade para emular um telefone IP criando as mensagens de sinalização mencionadas, enviá-los para um servidor de telefonia IP, e processar a resposta para verificar o funcionamento correto deste último. Execute o script test-signaling.sh em ambos os contêineres, que executa a ferramenta “SIPp” para gerar e enviar mensagens de sinalização para o IP-telefonia-servidor-VNF. Verifique a tela do cenário fornecida pela execução da etapa anterior. A recepção da resposta “200” mostra o funcionamento adequado do IP-telefonia-servidor-VNF. Validar que o serviço de rede pode processar o tráfego de dados que é gerado durante uma chamada de telefonia IP. Para isso, o fluxo de agendamento “Trafic” ferramenta31 é instalado no “IP-phone-a” e “IP-phone-b” recipientes Linux. Executar o seguinte comando para iniciar o agente de servidor de Trafic: lxc exec IP-phone-b sh called-party.sh. Em seguida, executar o seguinte comando para iniciar o agente cliente da Trafic e obter as estatísticas de rede: lxc exec IP-phone-a sh caller.sh. O tráfego de dados que emula uma chamada de voz é encerrado após 60 s. O script exibe uma mensagem de confirmação e as métricas de desempenho mais significativas sobre o tráfego de voz. Verifique as métricas obtidas e verifique se o serviço de telefonia IP pode efetivamente suportar uma conversa de voz interativa. Para isso, consulte as informações incluídas na seção sobre resultados representativos. 3. Construção de plataforma de nuvem de VANTs Selecione o modelo de SBC que pode fornecer o substrato de virtualização para executar VNFs leves. As especificações técnicas dos dispositivos SBC utilizados durante o experimento são: quatro CPUs, 1 GB de RAM e um disco de armazenamento de 32 GB. Além disso, cada SBC tem três interfaces de rede: uma interface Ethernet, uma interface Wi-Fi integrada e um adaptador USB Wi-Fi externo. Prepare os SBCs para serem posteriormente integrados à plataforma de nuvem de Vants. Instale o Ubuntu Mate32 16.04.6 como o sistema operacional, uma vez que os pacotes de instalação OpenStack estão incluídos nesta distribuição de Linux. Instale e configure os pacotes necessários, conforme indicado na documentaçãoOpenStack 33 para permitir que os SBCs ajam como os nós de computação da plataforma de nuvem de Vants. Seguindo o guia anterior, habilite a utilização de contêineres Linux na configuração dos pacotes OpenStack. A virtualização do contêiner é usada devido às restrições de recursos dos dispositivos que normalmente podem ser abordo em VANTs de pequeno porte. No SBC, baixe e execute o roteiro rpi-networking-configuration.sh,disponível no repositório do experimento. Este script permite as comunicações sem fio dos SBCs, bem como a configuração necessária para permitir a criação de redes virtuais anexadas às interfaces sem fio. Baixe e execute o script VIM-networking-configuration.sh,disponível no repositório do experimento, no host que executa a plataforma de nuvem uav VIM. Este script supervisiona a criação das comunicações sem fio do VIM para permitir a troca de informações com os SBCs.NOTA: Uma vez que a rede está bem configurada e o VIM tem conectividade com os SBCs, o VIM integra-os automaticamente na plataforma de nuvem de Vants como unidades computacionais capazes de executar VNFs Crie uma zona de disponibilidade openstack para cada um dos SBCs. Isso permitirá a implantação de cada um dos VNFs leves do experimento em uma unidade de Vants apropriada. Para isso, faça login na interface gráfica do usuário fornecida pelo VIM com as credenciais de administrador, crie as zonas de disponibilidade na guia Administrator > System > Host Aggregates e edite cada zona de disponibilidade para adicionar o host apropriado (ou seja, cada SBC integrado na plataforma de nuvem dos Vants). Verifique a configuração correta da plataforma de nuvem uav. Para isso, acesse a guia Administrator > System > System Information com o mesmo login da etapa anterior e clique na seção de Serviço de Computação e Agentes de Rede para verificar se o status dos itens exibidos é “Alive” e “UP”. 4. Configurando o experimento Baixe as imagens vnf que implementam os diferentes componentes do serviço de telefonia IP: o AP-VNF, o DNS-VNF, IP-telefonia-servidor-VNF, o AR-VNF, e o CR-VNF. Essas imagens podem ser baixadas do repositório do experimento. Envie as imagens do VNF para seu correspondente VIM (ou seja, a AP-VNF e a DNS-VNF para a plataforma de nuvem de UAV VIM) e a VoIP-VNF para a plataforma de nuvem principal VIM. Para fazer isso, faça login na interface gráfica do usuário fornecida por cada VIM com as credenciais de administrador, clique no botão Criar Imagem da guia Administrator > System > Images e crie uma imagem usando o formulário exibido e selecione a imagem apropriada. Este processo é feito no VIM correspondente para cada imagem que foi baixada na etapa anterior. Baixe os descritores vnf (VNFDs) do experimento a partir do repositório do experimento. Esses descritores fornecem os modelos que descrevem os requisitos operacionais de um VNF, bem como as políticas de colocação que indicam a zona de disponibilidade encarregada de hospedar o próprio VNF. Mais informações sobre descritores NFV podem ser encontradas no modelo de informação da OSM34. Envie os VNFDs. Use um navegador web para acessar a interface gráfica do usuário do OSM e entre com as credenciais de administrador. Em seguida, arraste e solte os VNFDs na aba VNF Packages. Baixe o descritor de serviços de rede (NSD) do repositório do experimento. Este descritor é um modelo que especifica os VNFs que compõem o serviço, bem como como esses VNFs estão interligados. Faça o upload do NSD. Arraste e deixe cair o NSD na aba ns pacotes da interface gráfica do usuário osm. Usando a interface gráfica do usuário da OSM, adicione uma conta VIM para a plataforma de nuvem de Vantvim e para a plataforma de nuvem principal VIM. Para fazer isso, acesse a guia contas VIM com as credenciais do administrador, clique no botão + Novo VIM e preencha o formulário exibido com as informações solicitadas. Repita esta ação para ambos os VIMs. 5. Executar o experimento Implantar o serviço de rede. A partir da aba de pacotes NS da interface gráfica do usuário osm, clique no botão Instantiate NS do NSD carregado na etapa 4.6. Em seguida, preencha o formulário exibido, indicando o VIM que será usado para implantar cada VNF compondo o NS. Além disso, a OSM é responsável pelo processamento das políticas de colocação indicadas nos VNFDs para especificar ao VIM qual zona de disponibilidade (ou seja, uma unidade de computação em nosso testbed) é responsável por hospedar cada VNF. Para este experimento, os VNFs são colocados nas unidades de computação, como ilustrado na Figura 1.NOTA: Como um método alternativo, o OSM fornece uma interface de linha de comando que permite a interação direta do usuário. Um usuário que reproduz este experimento pode usar essa interface de linha de comando, em vez da interface gráfica, para executar as diferentes etapas definidas neste protocolo, particularmente aquelas etapas relacionadas com a integração de um VNF ou um descritor ns, bem como a implantação de um serviço de rede. Espere até que a interface gráfica do usuário do OSM indique o sucesso na implantação do serviço de rede.NOTA: A operação do serviço de rede é totalmente independente do voo dos VANTs: O serviço de telefonia IP pode ser fornecido quando os VANTs estão voando ou economizando o consumo de baterias empoleirado em uma superfície. Assim, a etapa 5.3 é opcional. Tire os VANTs. Faça login no aplicativo móvel e controle o voo de cada Vant para mantê-lo de forma evigorada em uma altura intermediária e evitar a turbulência causada pela rotação dos motores perto de uma superfície. Prepare cada um dos telefones IP para realizar a chamada. Conecte um telefone VoIP sem fio a cada um dos pontos de acesso oferecidos pelo serviço de rede. Para isso, especifique o SSID(Identificadorde Conjunto de Serviços) na seção Menu > Wireless > SSID e escolha o modo de infraestrutura na seção Menu > Wireless > Network Mode. Finalmente, selecione a configuração de rede através do Dynamic Host Configuration Protocol (DHCP) na guia Menu > Net Settings > Network Mode. Configure os parâmetros do Protocolo de Iniciação de Sessão (SIP) para permitir a troca adequada de mensagens de sinalização com o servidor de telefonia IP. Neste contexto, o acesso à guia Menu > SIP Configurações e especifica o nome de anfitrião do servidor de telefonia IP VNF (“dronesVoIP.net”) nas abas Registrar > Registrar IP e Proxy Server > Proxy IP. Além disso, crie uma conta de usuário que introduz o nome do usuário (por exemplo, chamador-A) nas seções de usérão > número de telefone e conta de usuário > seções de nome de usuário. Crie uma entrada na lista telefônica de um dos telefones IP fornecendo as informações do usuário que deve ser chamado. Para fazer isso, selecione o Menu > Phonebook > Adicione a guia Entrada e preencha os parâmetros solicitados que aparecem na tela da seguinte forma: Nome de exibição = chamador-B; Informações do usuário = chamador-B; Host IP = dronesVoIP.net; Porto = 5060. Finalmente, selecione a opção “Proxy” em relação ao P2P (peer-to-peer). Comece a chamada para a outra parte. Para fazer isso, selecione a chamada festa usando o Menu > Phonebook > Opção de pesquisa do telefone IP. Em seguida, pressione o botão de chamada. Uma vez que o outro telefone IP começa a tocar, aceitar a chamada recebida com o botão de chamada. 6. Procedimento para reunir resultados experimentais Conecte um laptop de commodities a um dos APs sem fio e execute a ferramenta de linha de comando de ping para o endereço IP do telefone conectado ao outro AP durante 180 s. O endereço IP pode ser verificado no Menu > Information > opção de endereço IP do telefone IP uma vez que a conexão é estabelecida com o AP. Save the Round-Trip Time (RTT) medições, redirecionando a saída fornecida pela ferramenta de ping em um arquivo. Execute a ferramenta de linha de comando tcpdump em um dos VNFs AP em execução para capturar o tráfego trocado durante a chamada IP. Salve esse tráfego em um arquivo que permita a bandeira de escrita da ferramenta de linha de comando no momento da execução e especificando o nome do arquivo. Realize uma nova chamada de telefonia IP. Mantenha a chamada para o período de tempo desejado (por exemplo, 1 min). Em seguida, encerrar a chamada, pressionando o botão de desligar de um dos telefones IP. Mantenha os arquivos gerados pelas ferramentas de tcpdump e ping para processamento adicional. Veja os resultados representativos.

Representative Results

Com base nos dados obtidos durante a execução do experimento, em que uma chamada VoIP real é executada e seguindo as etapas indicadas pelo protocolo para coletar essas informações, a Figura 2 retrata a função de distribuição cumulativa do atraso de ponta a ponta medido entre dois itens de equipamento do usuário final (ou seja, um laptop de commodities e um telefone IP). Este equipamento de usuário representa dois dispositivos que estão interligados através dos VNFs AP do serviço de rede implantado. Mais de 80% das medições de atraso de ponta a ponta foram inferiores a 60 ms, e nenhuma delas foi superior a 150 ms, o que garante métricas de atraso adequadas para a execução de uma chamada de voz. A Figura 3 ilustra a troca de mensagens de sinalização DNS e SIP. Essas mensagens correspondem ao registro de um dos usuários no servidor de telefonia IP (ou seja, o usuário cujo telefone IP está conectado ao VNF AP onde a “ferramentatcpdump” está sendo executado) e ao estabelecimento da chamada de voz. Finalmente, a Figura 4 e a Figura 5 mostram o tráfego de dados capturado durante a chamada. Em particular, o primeiro representa o fluxo constante de pacotes de voz transmitidos e recebidos por um dos telefones sem fio durante a chamada, enquanto este último ilustra o nervosismo na direção de frente com um valor médio inferior a 1 ms. Os resultados obtidos no experimento para os números de atraso (atraso e nervosismo de ponta a ponta) satisfazem as recomendações especificadas pela União Internacional de Telecomunicações – Setor de Padronização de Telecomunicações (ITU-T)35. Assim, a chamada de voz progrediu sem falhas e boa qualidade de som. Este experimento validou a viabilidade prática do uso de tecnologias NFV e VANTs para implantar um serviço funcional de telefonia IP. Figura 1: Visão geral do serviço de rede, representando os VNFs, as entidades em que são executados, e as redes virtuais necessárias para a prestação do serviço de telefonia IP. Clique aqui para ver uma versão maior deste número. Figura 2: Atraso de ponta a ponta. Representação do atraso de ponta a ponta oferecido ao equipamento do usuário final conectado aos VNFs AP. Para isso, a função de distribuição cumulativa do atraso de ponta a ponta foi calculada a partir das amostras rtt medidas obtidas com a ferramenta de linha de comando “ping”ping”. Clique aqui para ver uma versão maior deste número. Figura 3: Registro de usuários e mensagens de sinalização de chamadas. Ilustração do tráfego de sinalização (DNS e SIP) trocada para registrar um usuário no servidor de telefonia IP e para criar e encerrar a sessão multimídia que suporta a execução da chamada de voz. Clique aqui para ver uma versão maior deste número. Figura 4: Fluxo de pacotes de voz. Representação do tráfego de voz trocada durante a chamada, medida em um dos VNFs AP. (Abreviaturas: RX = receber, RX = transmitir, RTP = protocolo de transporte em tempo real). Clique aqui para ver uma versão maior deste número. Figura 5: Evolução do nervosismo da rede durante a chamada. Representação do nervosismo experimentado pelos pacotes de voz transmitidos na direção para a frente de um telefone para o outro. Clique aqui para ver uma versão maior deste número.

Discussion

Um dos aspectos mais importantes deste experimento é o uso de tecnologias de virtualização e padrões NFV com plataformas uav. A NFV apresenta um novo paradigma com o objetivo de dissociar a dependência de hardware das funcionalidades da rede, permitindo assim o fornecimento dessas funcionalidades por meio da softwarization. Assim, o experimento não depende do uso do equipamento de hardware especificado no protocolo. Alternativamente, diferentes modelos de computadores de placa única podem ser selecionados, desde que estejam em linha com as dimensões e a capacidade de transporte dos VANTs e suportem contêineres Linux.

Não obstante essa flexibilidade em termos de seleção de hardware, todo o conteúdo fornecido para a reprodutibilidade do experimento é orientado para o uso de tecnologias de código aberto. Neste contexto, os aspectos de configuração e as ferramentas de software são condicionados ao uso do Linux como sistema operacional.

Por outro lado, o experimento considera a interoperação de duas plataformas computacionais diferentes (ou seja, a plataforma de nuvem uav e a plataforma de nuvem principal) para fornecer um serviço de rede moderadamente complexo. No entanto, isso não é estritamente necessário, e o protocolo poderia ser seguido para apoiar cenários em que apenas a plataforma de nuvem de Vants está envolvida.

Além disso, a solução apresentada poderia ser usada em outros ambientes, onde plataformas de hardware com restrição de recursos podem estar disponíveis com a capacidade necessária para executar contêineres de virtualização (por exemplo, a Internet das Coisas, ou IoT, ambientes). Em qualquer caso, a aplicabilidade desta solução para diferentes ambientes e suas adaptações potenciais exigirá um estudo cuidadoso caso a caso.

Finalmente, deve-se notar que os resultados apresentados foram obtidos em um ambiente de laboratório e com os dispositivos UAV aterrados ou seguindo um plano de voo limitado e bem definido. Outros cenários envolvendo implantações ao ar livre podem introduzir condições que afetam a estabilidade do voo dos VANTs e, portanto, o desempenho do serviço de telefonia IP.

Disclosures

The authors have nothing to disclose.

Acknowledgements

Este trabalho foi parcialmente apoiado pelo projeto Europeu H2020 5GRANGE (acordo de subvenção 777137), e pelo projeto 5GCIty (TEC2016-76795-C6-3-R), financiado pelo Ministério da Economia e Competitividade espanhol. O trabalho de Luis F. Gonzalez foi parcialmente apoiado pelo projeto Europeu H2020 5GinFIRE (acordo de subvenção 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