Integração de infraestruturas de experimentação 5G em um ecossistema NFV multi-local

Summary

O objetivo do protocolo descrito é apoiar a incorporação flexível de infraestruturas de experimentação 5G em um ecossistema NFV de vários locais, por meio de uma arquitetura de rede de sobreposição baseada em VPN. Além disso, o protocolo define como validar a eficácia da integração, incluindo uma implantação de serviço vertical multi-local com pequenos veículos aéreos compatíveis com NFV.

Abstract

A Virtualização da Função de Rede (NFV) tem sido considerada uma das principais facilitadoras para a^5ª Geração de redes móveis, ou 5G. Esse paradigma permite reduzir a dependência de hardware especializado para implantar telecomunicações e serviços verticais. Para isso, conta com técnicas de virtualização para softwarize funções de rede, simplificando seu desenvolvimento e reduzindo o tempo e os custos de implantação. Nesse contexto, a Universidad Carlos III de Madrid, a Telefónica e o IMDEA Networks Institute desenvolveram um ecossistema NFV dentro da 5TONIC, um centro de inovação de rede aberta focado em tecnologias 5G, possibilitando a criação de cenários complexos e próximos à realidade em um conjunto distribuído de infraestruturas NFV, que podem ser disponibilizadas por partes interessadas em diferentes locais geográficos. Este artigo apresenta o protocolo que foi definido para incorporar novos sites remotos de NFV no ecossistema NFV multi-local baseado no 5TONIC, descrevendo os requisitos tanto para as infraestruturas existentes quanto as recém-incorporadas, sua conectividade através de uma arquitetura de rede sobreposta e as etapas necessárias para a inclusão de novos sites. O protocolo é exemplificado através da incorporação de um local externo ao ecossistema 5TONIC NFV. Posteriormente, o protocolo detalha as etapas de verificação necessárias para validar uma integração bem-sucedida do site. Estes incluem a implantação de um serviço vertical de vários locais usando uma infraestrutura NFV remota com Veículos Aéreos Não Tripulados (SEUSVs). Isso serve para mostrar o potencial do protocolo para viabilizar cenários de experimentação distribuídos.

Introduction

A introdução da quinta geração de redes móveis (5G) implica revolucionar a indústria de telecomunicações desde o início da década, exigindo que as operadoras de telecomunicações abdoem as especificações muito mais exigentes dos novos serviços e aplicações de rede desenvolvidos sob o guarda-chuva 5G^1,2 . Essas novas especificações incluem, mas não se limitam a, aumentos na taxa de dados, melhorias na latência da transmissão sem fio e redução de custos operacionais. Entre as tecnologias que constituem os fundamentos das melhorias para essa nova geração, a Virtualização de Funções de Rede³ (NFV) tornou-se um de seus principais facilitadores. A NFV oferece a capacidade de softwarize funções de rede, tradicionalmente retransmitindo em hardware especializado, usando equipamentos físicos genéricos, como computadores de servidor em um datacenter. Com esse novo paradigma, as operadoras de telecomunicações e as indústrias verticais podem implantar funções e serviços de rede como um conjunto de componentes de software, além de economizar custos tanto na implantação e manutenção do serviço, além de facilitar uma elasticidade de infraestrutura de rede muito maior. Essa abordagem alivia ou elimina a necessidade de usar dispositivos dedicados (e geralmente mais complexos e menos reutilizáveis) para a maioria das funções específicas da rede e da vertical, e suporta um grau muito maior e mais denso de automação operacional, reduzindo assim os custos de implantação e manutenção.

Levando em consideração todas as vantagens que um ambiente NFV é capaz de proporcionar, é natural que um grande número de stakeholders relevantes do setor de telecomunicações tenham se envolvido cada vez mais no teste de novas ideias de serviços em ambientes NFV. Nesse contexto, a Telefónica e o IMDEA Networks Institute criaram o 5TONIC⁴, um laboratório aberto de pesquisa e inovação focado em tecnologias 5G. Com sede em Madri (Espanha), este laboratório possui uma ampla gama de tecnologias disponíveis para pesquisas e parceiros para impulsionar o desenvolvimento e validação de serviços 5G. Em particular, este laboratório possui uma plataforma experimental NFV onde os desenvolvedores são capazes de implantar e testar seus novos aplicativos e serviços baseados em NFV em um ecossistema NFV compatível com ETSI⁵. Assim, conclusões experimentais sobre escolhas de design e propostas tecnológicas podem ser derivadas em um ambiente realista muito mais flexível do que as redes de produção. Esta plataforma foi projetada para suportar atividades de experimentação em vários sites externos, que podem ser flexívelmente interconectadas ao 5TONIC usando um protocolo bem definido.

A solução técnica adotada para o ecossistema 5TONIC NFV considera a utilização de um único orquestrador NFV, implementado usando o software DE Código Aberto MANO (OSM) hospedado no ETSI⁶. Este é o elemento responsável pela gestão e coordenação do ciclo de vida dos Serviços de Rede (NS). Esses serviços podem ser construídos como uma composição de Funções Virtualizadas de Rede/Vertical (VNF), que podem ser implantados em qualquer um dos locais integrados na plataforma NFV. O projeto do ecossistema 5TONIC NFV foi feito no contexto do projeto H2020 5GINFIRE^7,8, onde a plataforma foi usada para suportar a execução de mais de 25 experimentos, selecionados por meio de um processo competitivo de abertura, em oito infraestruturas experimentais verticais específicas localizadas na Europa e uma no Brasil, esta última conectada por meio de um link transoceânico. Além disso, a plataforma foi aproveitada para construir um NFV distribuído testado em escala nacional, na Espanha, apoiando atividades de experimentação dentro do projeto espanhol 5GCity^9,10. Mais recentemente, um site brasileiro adicional foi integrado à plataforma, para apoiar atividades conjuntas de demonstração no contexto de uma cooperação de pesquisa e inovação estabelecida entre Brasil e Europa (ou seja, o projeto 5GRANGE^11,12). Por último, mas não menos importante, a infraestrutura tem sido usada para suportar experimentos de terceiros no âmbito do projeto 5G-VINNI^13,14. A distribuição geográfica da plataforma NFV pode ser vista na Figura 1.

As organizações interessadas que hospedam sua própria infraestrutura NFV podem se conectar de forma flexível ao ecossistema 5TONIC NFV, sujeita à aprovação do 5TONIC Steering Board, tornar-se provedores testados dentro do ecossistema distribuído e estar envolvidas em atividades conjuntas de experimentação e demonstração. Para isso, eles devem apresentar um VIM (Virtual Infrastructure Manager) compatível com a pilha de software OSM. O orquestrador NFV 5TONIC é capaz de interagir com os VIMs nos locais envolvidos em uma determinada implantação de serviço, coordenando a alocação e configuração dos recursos de computação, armazenamento e rede necessários para a instantaneização e interconexão dos VNFs que compõem um serviço de rede e controlando seu ciclo de vida, desde seu embarque até seu descomissionamento final.

Para gerenciar a troca de controle e tráfego de dados em todos os sites interconectados, o ecossistema 5TONIC NFV faz uso de uma arquitetura de rede de sobreposição baseada em Redes Virtuais Privadas (VPN). Essa abordagem fornece acesso seguro baseado em PKI aos sites externos integrados ao ecossistema 5TONIC, permitindo a troca de informações de controle NFV entre a pilha de software OSM e os diferentes VIMs distribuídos nos locais de teste, bem como a troca de informações necessárias para gerenciar e configurar todos os VNFs. Além disso, essa rede de sobreposição suporta a disseminação do tráfego de dados entre VNFs que são implantados em diferentes locais.

Neste contexto, este artigo detalha o protocolo projetado para incorporar um site externo a um ecossistema NFV. O protocolo pressupõe que o ecossistema é regido por um único orquestrador NFV, instalado em um local central, e sites externos apresentam uma solução VIM compatível com a pilha de software do orquestrador. O protocolo proposto permite incrementar o portfólio de recursos do ecossistema experimental, com a incorporação flexível de locais NFV e infraestruturas verticais específicas. Isso permite a criação de uma plataforma MANO distribuída capaz de testar e validar novos serviços de rede e vertical em vários sites, sob o controle de um único orquestrador NFV. Para ilustrar o funcionamento interno do protocolo, o processo será exemplificado adicionando um site externo de NFV ao atual ecossistema 5TONIC NFV, descrevendo os componentes necessários no local externo e no 5TONIC, bem como todas as medidas a serem tomadas durante o processo de integração. A Figura 2 fornece uma visão geral do objetivo da integração, com o novo testbed baseado em NFV anexado à plataforma 5TONIC de onde os serviços de rede podem ser implantados, por meio de conexões VPN entre o local central e o resto das infraestruturas externas.

Além disso, para mostrar a eficácia do protocolo, será mostrada a implantação de um serviço vertical simples, utilizando o ecossistema 5TONIC e um local externo com veículos aéreos não tripulados (SUASVs) compatíveis com NFV. O design do serviço vertical foi inspirado em um experimento apresentado em Vidal et al.⁹, que foi simplificado para fins de ilustração deste artigo. A Figura 3 descreve o serviço, que visa auxiliar atividades agrícolas inteligentes em uma área remota. O serviço considera um prestador de serviços de agricultura inteligente que usa SUASVs para coletar e disseminar os dados produzidos por sensores meteorológicos espalhados por um campo de cultivo. Para simplificar, o experimento apresentado no artigo considera um único SUAV e um sensor, capaz de fornecer medidas de temperatura, umidade e pressão. No experimento, o site externo do NFV hospeda um ponto de acesso Wi-Fi que é implantado como VNF sobre o SUAV. Este VNF oferece conectividade de acesso à rede ao sensor, encaminhando os dados sentidos para uma função gateway. Este último é implantado como um VNF em um equipamento terrestre (um computador mini-ITX). A disseminação de dados do sensor para a função gateway segue uma abordagem publicar/assinar com base no protocolo MQTT (Message Queuing Telemetry Transport, transporte de telemetria)¹⁵. A função gateway processa e, em seguida, dissemina os dados para um servidor de Internet das Coisas (IoT), que é disponibilizado como um VNF no local central do ecossistema NFV, com base na plataforma mainflux¹⁶ de código aberto. Finalmente, o cenário assume uma área remota onde a conectividade com a Internet é fornecida por uma rede de acesso celular não 3GPP. Assim, o serviço inclui dois VNFs adicionais: 1) um roteador de acesso VNF, que implementa a pilha de protocolos de plano de usuário de um equipamento de usuário 3GPP conectado a uma rede de acesso não-3GPP¹⁷; e 2) uma implementação de linha de base de uma rede core 5G, suportando o encaminhamento de informações entre o roteador de acesso e os VNFs do servidor IoT. Para isso, o núcleo 5G VNF fornece uma implementação simplificada do plano de usuário de uma função de intertrabalho não-3GPP e uma função de plano de usuário, conforme definido pelo 3GPP¹⁷.

Por fim, a Figura 4 representa os processos mais relevantes envolvidos durante o desenvolvimento do protocolo, destacando suas interconexões lógicas e as entidades responsáveis por sua execução.

Protocol

1. Provisão do local central do ecossistema NFV (requisitos prévios do experimento)

1. Aloque um espaço de endereço IP a ser usado pelo site central. Para efeitos deste protocolo, será utilizado o espaço de endereço privado 10.4.0.0/16.
2. Instale a pilha de software de Gerenciamento e Orquestração (MANO) no local central. Em particular, o experimento realizado ao longo deste protocolo utiliza a Versão SETE¹⁸(Open Source MANO) (OSM), que requer os seguintes recursos: Ubuntu 18.04 como sistema operacional, 2 Unidades Centrais de Processamento (CPUs), 8 GB de Memória de Acesso Aleatório (RAM), disco rígido de 40 GB e pelo menos uma interface de rede com acesso à Internet. Para a instalação, siga as instruções disponíveis na documentação¹⁸da OSM Release SEVEN .
3. Configure um Gerenciador de Infraestrutura virtual (VIM) compatível com os OSM no local central. Especificamente, o experimento usa a versão OpenStack Ocata²⁰, rodando em uma Máquina Virtual (VM) com Ubuntu 16.04 , 4 CPUs, 16 GB de RAM e 200 GB de disco rígido. A Infraestrutura NFV (NFVI) manuseada por este VIM compreende três computadores de servidor, cada um com Ubuntu 16.04, 8 CPUs, 32 GB de RAM e 2 TB de armazenamento. Para a instalação, siga a documentação de liberação da Ocata²¹.
   1. Implante uma rede virtual dentro da plataforma de nuvem OpenStack, usando uma faixa de endereço IP do espaço de endereço alocado na etapa 1.1. Esta rede, a partir de agora referida como rede de gerenciamento, será usada para apoiar a troca de informações de orquestração NFV entre o OSM e as funções de rede virtual (VNFs) instaiadas no local central.
   2. Configure uma rede virtual (a partir de agora denominada como rede de dados) para suportar comunicações de dados entre sites, entre as VNFs do site central e outras VNFs executadas em locais externos. Para isso, use uma faixa de endereço IP a partir do espaço de endereço da etapa 1.1.
      NOTA: A implementação das redes mencionadas nas etapas 1.3.1 e 1.3.2 foi feita utilizando redes de provedores do OpenStack. As redes de provedores devem estar conectadas à infraestrutura de rede física do local central para garantir uma operação adequada.
4. Conecte tanto as redes virtuais privadas (ou seja, o gerenciamento e as redes de dados), bem como as máquinas VIM e OSM, a um equipamento que fornece funcionalidades de roteamento de borda. Este roteador servirá como ponto de entrada para o local central do ecossistema NFV.
5. Disponibilize um repositório público de experimentos para fornecer todo o conteúdo necessário para realizar o experimento. Em particular, este protocolo usa o repositório público em²².

2. Configuração do serviço de rede privada virtual

1. Aloque um espaço de endereço IP para suportar a operação adequada do ecossistema de vários locais, para que as comunicações de rede possam ser efetivamente estabelecidas entre vários sites.
   NOTA: Permitir comunicações de rede eficazes entre vários sites requer um design cuidadoso do espaço de endereço IP para ser usado pelo ecossistema NFV, bem como por sites externos que precisam se conectar a ele. Em particular, o espaço de endereço alocado para comunicações inter-local não deve colidir com o espaço de endereço já em uso em todos os outros sites para outros fins.
   1. Aloque um espaço de endereço IP para ser usado por sites externos. Os endereços deste bloco serão atribuídos a entidades NFV (por exemplo, VIMs) e VNFs do site externo. Para exemplificar este protocolo, será utilizado o espaço de endereço privado 10.154.0.0/16.
   2. Aloque um espaço de endereço IP para os links virtuais entre os sites externos e o ecossistema NFV. Esses links virtuais serão suportados por um serviço de VPN. Para exemplificar este protocolo, a faixa de endereço 10.154.254.0/24 será utilizada para esses links virtuais.
2. Configure um equipamento para fornecer o serviço Virtual Private Network (VPN) (ou seja, um servidor VPN). Em particular, o experimento usa um computador de servidor com Ubuntu 16.04 (imagem variante de 64 bits), seis CPUs independentes, RAM de 16 GB, disco de armazenamento de 1 TB e duas interfaces de rede.
   1. Configure uma das interfaces de rede do servidor VPN para permitir a recepção de solicitações de conexão de sites externos através da Internet. Para isso, é necessário usar uma interface do servidor configurada com um endereço IP público.
   2. Configure o link entre o servidor VPN e o roteador de borda do site central. No experimento, este link foi alocado na faixa de endereço 10.4.255.0/24. Configure rotas de rede apropriadas no servidor VPN, para que o ecossistema NFV se torne acessível a partir de sites externos conectados ao serviço VPN.
3. Instale o software de código aberto VPN fornecido pelo projeto OpenVPN²³ no servidor VPN. Especificamente, este experimento usa a versão 2.3.10 do OpenVPN, e sua implantação foi feita com o script bash "openvpn-install.sh", disponível em http://github.com/Nyr/openvpn-install (outras opções de instalação estão descritas na documentação OpenVPN ²⁴). O script bash apresenta os parâmetros alternativos que resultarão na configuração do serviço VPN.
   1. Selecione o endereço IP para ouvir as solicitações de conexão VPN (ou seja, o endereço IP público).
   2. Decida qual protocolo (UDP ou TCP) deve ser usado para conduzir as comunicações sobre a VPN. Neste caso, o experimento aproveita o UDP que é o protocolo recomendado.
   3. Especifique a porta que incluirá o duple (juntamente com o endereço IP público) que será usado para receber as solicitações de conexão de serviço. Por padrão, o valor atribuído é 1194.
   4. Escolha um dos servidores DNS da lista solicitada pelo assistente que atenderá às solicitações de resolução de nome realizadas pelos clientes do serviço VPN.
   5. Pressione qualquer tecla para ativar o início automático do processo de instalação do serviço VPN.
4. Edite o arquivo de configuração "server.conf" que está localizado no diretório "/etc/openvpn/server/" e inclua a diretiva "cliente-cliente" com o objetivo de estender a configuração básica fornecida pelo passo 2.3. Assim, diferentes clientes conectados ao serviço VPN poderão se alcançar.
5. Habilite a configuração de cliente individual dentro da configuração VPN para gerenciar independentemente as atribuições de roteamento de cada cliente.
   1. Adicione a diretiva "cliente-config-dir ccd", editando o mesmo arquivo de configuração da etapa 2.4.
   2. Crie o diretório "ccd" usando o comando "mkdir /etc/openvpn/ccd/". Este diretório servirá durante a próxima seção do protocolo para colocar os arquivos que compreendem as diretrizes de roteamento associadas aos clientes destinados a serem integrados dentro da plataforma.
6. Configure as regras de firewall necessárias para permitir as conexões com o serviço, protegendo o servidor VPN contra ataques maliciosos. Para isso, este experimento aproveita o iptables²⁵, que é um utilitário de linha de comando desenvolvido para configurar o firewall do kernel Linux.
   1. Primeiro, bloqueie o tráfego de entrada para o servidor VPN com o comando "iptables -P INPUT DROP".
   2. Permitir a recepção de solicitações de conexão VPN com os comandos "iptables -A INPUT -i -m state --state NEW -p udp --dport 1194 -j ACCEPT" ( é o nome da interface do servidor VPN com o endereço IP público) e "iptables -A INPUT -i tun+ -j ACCEPT".
   3. Permitir o encaminhamento de tráfego entre as interfaces do servidor VPN (ou seja, a interface pública e a interface virtual criada pelo serviço VPN chamado tun0), para permitir que o servidor VPN processe a solicitação de conexão de serviço. Para isso, execute o comando "iptables -A FORWARD -i tun+ -o -m state RELATED,ESTABLISHED -j ACCEPT && iptables -A FORWARD -i -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT".
   4. Habilite o servidor VPN para fornecer o recurso de tradução de endereço de rede (NAT) com o objetivo de fornecer acesso à Internet para o site central, executando: "iptables -t nat -A POSTROUTING -s 10.4.0.0/16 -o -j MASQUERADE && iptables -A OUTPUT -o tun+ -j ACCEPT".

3. Integração de um site externo do NFV

1. Obtenha uma faixa de endereço IP apropriada para integrar o site ao ecossistema NFV. Esta faixa de endereços será fornecida pelo centro de operações de rede do ecossistema NFV. De acordo com a etapa 2.1.1 deste protocolo, o experimento usará uma gama de endereços IP para o site externo dentro de 10.154.0.0/16.
2. Crie e forneça as credenciais de segurança para se conectar ao ecossistema NFV.
   1. Gere uma credencial VPN que permitirá que a nova infraestrutura estabeleça uma conexão segura com o servidor VPN. Para isso, execute o comando "bash openvpn-install.sh" no servidor VPN, selecione a opção "1) Adicione um novo cliente" da lista solicitada e forneça o nome a ser associado a essa credencial, por exemplo, uc3m_infrastructure. Esta etapa gerará um arquivo com as credenciais VPN (chamado "uc3m_infrastructure.ovpn" no exemplo).
   2. Crie um arquivo de texto no diretório "/etc/openvpn/ccd/" do servidor VPN, incluindo as diretivas de roteamento (conforme especificado na documentação OpenVPN ²⁴) que deve ser empurrada pelo servidor VPN cada vez que uma conexão com o serviço VPN for estabelecida usando as credenciais VPN.
      NOTA: O nome do arquivo de texto deve corresponder ao nome especificado durante a criação da credencial VPN (por exemplo, uc3m_infrastructure) para fornecer uma configuração personalizada para cada cliente VPN.
   3. Forneça o arquivo de credencial VPN à equipe técnica do site externo. Isso deve ser feito através de um canal seguro e confiável. Neste experimento, é usado um processo de criptografia manual. Para criptografar a credencial VPN, execute o comando "7za a -tzip '-p' -mem=AES256 ", configurando como a chave de criptografia desejada, como o nome escolhido para o arquivo criptografado e como o nome do arquivo de arquivo do arquivo credencial VPN (por exemplo, uc3m_infrastructure.ovpn).
   4. Forneça a credencial criptografada para a equipe técnica do novo site, juntamente com a chave que permite os procedimentos de descriptografia, através de um canal de comunicação seguro.
      NOTA: Neste experimento, as credenciais criptografadas foram fornecidas por e-mail eletrônico, enquanto a chave de descriptografia foi enviada através de um canal separado, usando o serviço de mensagem curta (SMS), com um acordo off-line do número de telefone.
3. Configure o ambiente no novo local, de modo a estabelecer a conexão com o ecossistema NFV e permitir que o NFVI remoto seja anexado à pilha OSM do local central.
   1. Instale o software VPN fornecido pelo OpenVPN²⁴ em um computador, para permitir um link virtual entre o site externo e o local central do ecossistema NFV. O computador com o software OpenVPN servirá como cliente VPN ou ponto final VPN no site externo. O link virtual será realizado por meio de um túnel VPN protegido entre o ponto final da VPN e o servidor VPN. No experimento, o ponto final da VPN é executado em um computador de servidor com Ubuntu 18.04, 8 CPUs, 8 GB de RAM, disco de armazenamento de 128 GB e interfaces de 3 GbE (uma para conexão com o serviço VPN via Internet).
   2. Ative o encaminhamento de IP no ponto final da VPN para suportar recursos de roteamento de rede. Para isso, inclua a linha "net.ipv4.ip_forward=1" no arquivo de configuração do sistema localizado no caminho "/etc/sysctl.conf" e carregue a configuração atualizada com o comando "sudo sysctl -p".
   3. Descriptografar o arquivo de credencial VPN com as informações recebidas na etapa 3.2.4, usando o comando "7za e ", onde o arquivo is o nome do arquivo da credencial VPN criptografada. Especifique a tecla de descriptografia quando solicitada pelo comando.
   4. Inicializar o software OpenVPN com o arquivo credencial descriptografado usando o comando "sudo openvpn --config " ( é o nome do arquivo da credencial VPN). Com isso, o ponto final da VPN será autenticado para o servidor VPN e receberá automaticamente parâmetros de configuração vpn apropriados e rotas de rede. Dessa forma, o ponto final da VPN se comportará como um roteador de borda com um link virtual para o local central do ecossistema NFV.
   5. Verifique o bom funcionamento do ponto final da VPN, utilizando o comando ping para verificar a disponibilidade de conectividade a um dos nódulos do local central (por exemplo, o equipamento de pilha OSM).
   6. No novo site, selecione um VIM compatível com OSM para permitir operações com a plataforma MANO. Para este experimento, o OpenStack libera Ocata.
      NOTA: O OSM Release SEVEN suporta os seguintes gerentes de infraestrutura virtual: OpenStack, OpenVIM²⁶, VMware's vCloud Director²⁷, Amazon Web Service^28,Microsoft Azure²⁹e Eclipse fog05³⁰ (consulte documentação DOM¹⁸ para detalhes específicos de configuração).
   7. Instale o OpenStack release Ocata²⁰ (veja os procedimentos detalhados na documentação de liberação²¹).
   8. Implante a infraestrutura NFV no local externo e conecte-a ao VIM. Em particular, este experimento usa uma infraestrutura NFV composta por três computadores de placa única (SBCs), cada um com uma capacidade computacional de 1 GB de RAM, 4 CPUs e disco de armazenamento de 32 GB; e um único computador mini-ITX com 8 CPUs, 8 GB de RAM e 128 GB para armazenamento.
      NOTA: O site externo exemplificado neste protocolo é baseado em uma infraestrutura NFV de pequenos veículos aéreos não tripulados (SUASVs) com capacidade para a NFV . Os detalhes seguidos para habilitar tal infraestrutura são fornecidos em Nogales et al³¹. As etapas 3.3.6 a 3.3.8 são opcionais, pois uma infraestrutura NFV já pode existir no local externo.
   9. Crie um projeto OpenStack para especificar o conjunto de recursos computacionais do site externo que será integrado ao ecossistema NFV. Para isso, acesse a interface gráfica de usuário (GUI) fornecida pelo OpenStack, faça login no sistema com as credenciais do administrador, clique no botão + Criar projeto da guia Projetos de identidade -> e crie um projeto completando o formulário exibido com as informações solicitadas.
   10. Crie um usuário válido que gerenciará o projeto criado na etapa anterior. Para isso, acesse a guia Identidade -> Usuários com o mesmo login da etapa anterior, clique em + Criar Usuário e preencha os campos necessários do formulário exibido (nome de usuário e senha), selecionando o novo projeto criado como o projeto principal e escolhendo a função de administrador.
   11. Modifique as regras de segurança para permitir permissões de comunicação VNF no novo site (em particular, habilite o tráfego de SSH e ICMP). Para isso, acesse o Gui OpenStack com as credenciais do usuário criadas na etapa anterior, siga a sequência: Project -> Network -> Security Groups -> + Add Rulee selecione a opção SSH da regra drop-down. Repita o processo, mas selecione a opção Tudo ICMP incluído no menu suspenso.
   12. Baixe as imagens de um serviço de teste oferecido pela comunidade OSM, o serviço de rede Ping Pong ("Fedora-x86_64-20-20131211.1-sda-ping" e "Fedora-x86_64-20-20131211.1-sda-pong") do repositório de experimentos públicos, e envie-os para o VIM do site externo. Para isso, siga a sequência Project -> Compute -> Images -> + Criar imagem, e crie as imagens usando a forma exibida e selecionando cada uma das imagens.
   13. Atribua duas faixas de endereço IP no espaço de endereço do site externo (alocado na etapa 3.1). Essas faixas serão utilizadas para apoiar o gerenciamento dos VNFs do site externo e para permitir a comunicação de dados entre vnfs entre vnfs, respectivamente.
   14. Crie uma rede de provedores(provedor de controle)usando o VIM. Esta rede suportará comunicações NFV entre a pilha OSM no local central e os VNFs implantados no novo local para fins de gerenciamento. Esse tipo de comunicação também permitirá que a pilha OSM configure VNFs após sua implantação. Para criar uma rede de provedores no OpenStack, siga a sequência Admin -> System -> Networks -> + Criar rede e preencha os detalhes da nova rede, usando a faixa de endereço IP selecionada na etapa anterior.
   15. Crie uma segunda rede de provedores(provedor de dados)usando o VIM. Esta rede suportará comunicações de dados entre os VNFs do site e outros VNFs do ecossistema NFV. Para criar essa rede de provedores no OpenStack, siga a sequência Admin -> System -> Networks -> + Create Networke preencha os detalhes da nova rede usando a faixa de endereço atribuída.
       NOTA: As instruções sobre como criar redes virtuais variam dependendo do software VIM. Verifique a documentação do software em seus respectivos detalhes.
   16. Compartilhe as informações relacionadas ao VIM (em particular, o nome de usuário/senha e o projeto criado nas etapas 3.3.9 e 3.3.10) com a equipe técnica do site central, para habilitar a anexação do VIM à pilha de software OSM.
4. Conecte a infraestrutura externa do NFV à pilha de software OSM do site central, usando as informações obtidas da etapa 3.3.16.
   1. Verifique a conectividade entre a pilha OSM do local central e a VIM do novo site, usando a ferramenta de ping.
   2. Se o teste de conectividade anterior for bem sucedido, conecte o VIM externo à pilha OSM do local central. Para isso, use o seguinte comando na máquina OSM: "osm vim-create --name --user --senha >--senha -auth_url --nome de --account_type ". Neste comando: é o nome selecionado para identificar o VIM dentro da pilha OSM, é o nome do usuário autorizado a lidar com os recursos do site externo (ver etapa 3.3.10), é a senha do usuário indicado, é o link para a API disponibilizado pelo VIM para habilitar solicitações da pilha OSM , é o nome do projeto definido na etapa 3.3.9, e é o software VIM usado (neste experimento, OpenStack).
5. Verifique a anexação adequada do novo VIM à pilha OSM do ecossistema NFV.
   1. Execute o comando "ro_id=$(docker ps | grep osm_ro | cut -d ' -f 1)" para identificar o id do contêiner que implementa o módulo Resource Orchestrator (RO) dentro do sistema OSM. Este módulo é o responsável por interagir com os VIMs, a fim de coordenar e alocar os recursos necessários na implantação de serviços de rede subsequentes.
   2. Acesse o contêiner RO usando o comando "docker exec -it $ro_id bash". Este comando utiliza o identificador obtido na execução da etapa anterior.
   3. Verifique se o novo VIM está incluído na lista de data centers disponíveis, usando o comando "openmano datacenter-list". O novo site deve aparecer na lista com o mesmo nome do anteriormente introduzido na etapa 3.4.2 com o parameter.
   4. Liste as imagens que foram enviadas para o VIM do site externo, usando o comando "openmano vim-image-list --datacenter ". O parametro indica o nome selecionado para identificar o VIM dentro da pilha OSM. Se a execução deste comando for bem sucedida, a conectividade com o VIM externo foi estabelecida com sucesso. Verifique se as imagens do Ping Pong estão incluídas na lista.
   5. Liste as redes disponíveis no novo site com o comando "openmano vim-net-list --datacenter ". Verifique se o provedor de controle e o provedor de dados estão presentes.
6. Realize uma validação preliminar da integração adequada do novo site, utilizando um serviço de teste oferecido pela comunidade OSM (todo o conteúdo a esse respeito está incluído no repositório de experimentos). Para isso, os comandos incluídos nas seguintes etapas serão executados no equipamento que hospeda a pilha OSM.
   1. A bordo dos descritores VNF (VNFDs) para a pilha OSM executando o comando "osm vnfd-create " para cada um dos VNFs que compõem o serviço de teste ( corresponde ao nome do arquivo do pacote VNFD).
   2. A bordo do descritor NS (NSD) do serviço de teste com o comando "osm nsd-create ", onde indica o nome do arquivo do pacote NSD (neste experimento, ping_pong_ns.tar.gz)."
   3. Inicie a instanciação do Serviço de Rede ping pong (NS) nos locais externos e centrais, usando o comando "osm ns-create -ns_name --nsd_name ping_pong_ns --vim_account --config '{vnf: [{member-vnf-index: '2', vim_account: }}}". O parametro identifica o VIM do local externo dentro da pilha OSM. A opção "-config" indica que todos os VNFs que compõem o serviço devem ser implantados no local externo manuseado por aquele VIM, exceto o VNF identificado pelo índice 2 no NS, que será implantado no local central (o VIM do local central é especificado no parametro).
   4. Verifique se o NS foi implantado e seu status usando o comando "osm ns-list". Se a instante é bem sucedida, o status mudará para "READY".
   5. Verifique o endereço IP de cada um dos dois VNFs com "osm vnf-list" (necessário para fazer login nas máquinas posteriormente).
   6. Conecte-se a cada VNF via SSH, usando o comando "ssh fedora@" ( representa o endereço IP do VNF para se conectar, obtido na etapa anterior). Introduza a senha "fedora" quando solicitada pelo SSH. Uma vez logado em ambas as máquinas, verifique suas interfaces usando o comando "ip address show" e obtenha os endereços IP em suas interfaces anexadas à rede do provedor de dados (interface eth1 em ambos os VNFs). A partir de um dos VNFs, execute um ping para o outro VNF, usando o endereço IP remoto na rede de provedor de dados. Se houver conectividade, o teste preliminar de validação será considerado bem sucedido.

4. Validação da plataforma multi-site NFV com um serviço vertical realista

1. Baixe as imagens VNF do repositório público e carregue-as no VIM de seu site correspondente (ver Figura 3), seguindo o procedimento detalhado na etapa 3.3.12. Em particular, o site externo hospedará o Access Point VNF, Router VNF, MQTT Gateway VNF e Access Router VNF. O site central hospedará o 5G Core VNF e o IoT Server VNF.
2. A bordo dos VNFDs e do NSD do serviço de agricultura inteligente para a pilha OSM (todos os descritores podem ser baixados do repositório de experimentos).
   1. A bordo dos VNFDs para a pilha OSM executando o comando "osm vnfd-create ", para cada um dos VNFs do serviço de rede. Neste caso, o parâmetro se corresponde ao nome do arquivo do pacote VNFD.
   2. A bordo do NSD para a pilha OSM com o comando "osm nsd-create ", onde indica o nome do arquivo do pacote NSD (neste experimento, jove_uavs_scenario_nsd.tar.gz).
3. Implantar o serviço de rede agrícola inteligente. Para este fim, execute o seguinte comando da interface da linha de comando OSM: osm ns-create --ns_name --nsd_name jove_uavs_scenario_nsd --vim_account --config '{vnf: { membro-vnf-index: "5", vim_account: }, {member-vnf-index: "6", vim_account: } ], wim_account: False }'.
   NOTA: Conforme indicado na etapa 3.6.3., os e metros indicam os locais onde os VNFs devem ser implantados. Particularmente, todos os VNFs que compõem o serviço de agricultura inteligente serão colocados no novo site externo, exceto aqueles com índice 5 e 6 (o 5G Core e os VNFs do servidor IoT)que serão alocados no local central.
4. Verifique se o NS foi implantado, seguindo o mesmo procedimento da etapa 3.6.4.
5. Acesse o servidor IoT VNF com o comando "ssh mosquittosubscriber@" e verifique sua interface configurada para se comunicar com o MQTT Gateway VNF através do comando "ip address show dev eth1". O endereço IP do VNF () pode ser obtido executando a "lista de vnfs" na linha de comando OSM.
6. Seguindo um procedimento análogo, acesse o MQTT Gateway VNFe execute o comando "sudo python3 publisher_MQTT_GW.py -ma -ba " onde o se obtido na etapa anterior, e o executando o comando "ip address show dev eth1" no MQTT Gateway VNF. Esta etapa inicializa o MQTT Gateway VNF, que receberá dados gerados pelo sensor usando o padrão MQTT^15,transmitindo esses dados para o servidor IoT VNF usando o mesmo padrão.
7. Prepare um Computador de Placa Única (SBC) anexando um sensor meteorológico e com capacidade de transceptor para transmitir leituras de sensores em direção ao MQTT Gateway VNF.
   NOTA: Para exemplificar este protocolo, um modelo SBC em particular foi usado. Portanto, as etapas a seguir podem precisar ser adaptadas no caso de utilizar uma plataforma SBC diferente.
   1. Conecte (por exemplo, usando fios de cobre soldados em lata) os pinos de placa do sensor aos pinos de entrada/saída (GPIO) de uso geral do SBC, seguindo o esquema de configuração da Figura 5.
   2. Habilite o módulo do kernel I2C no SBC para verificar se o sensor foi detectado. Para isso, execute o comando "sudo raspi-config", siga a sequência Interfacing Options -> I2C -> Sim no menu exibido e reinicie o SBC para tornar as alterações eficazes.
   3. Verifique se o sensor é detectado Instalando as ferramentas de software i2c no SBC e executando o comando "sudo i2cdetect -y 1". Nesse caso, uma grade deve aparecer indicando a posição onde o sensor é detectado.
   4. Instale as bibliotecas de software apropriadas para permitir a leitura e o envio dos dados fornecidos pelo sensor. Em particular, este experimento aproveita as bibliotecas RPi.bme280³² e opas-mqtt³³ Python.
8. Usando a aplicação móvel do SUAV, decole o veículo aéreo que hospeda o Access Point VNF, e posicione-o para fornecer cobertura sem fio ao SBC com o sensor.
   NOTA: O voo dos SUASVs compatíveis com NFV são independentes do comportamento operacional do serviço de rede, que é capaz de operar se os SUASVs estão voando ou em um estado de repouso para mitigar o consumo de bateria. Assim, o passo 4.8 é opcional.
9. Anexar o SBC responsável pela leitura dos dados coletados pelo sensor ao ponto de acesso sem fio Wi-Fi fornecido pelo Access Point VNF). Após um anexo bem-sucedido, um caminho de rede sem fio será ativado do sensor para o MQTT Gateway VNF.
10. Inicie a transmissão de dados sentidos, executando o comando "python3 /home/ubuntu/sensorDataTransmission.py -um " no SBC que incorpora o sensor ( é o endereço IP obtido na etapa 4.6.).
11. Acesse a GUI web fornecida pelo servidor IoT VNF para verificar a recepção correta em tempo real dos dados sentidos. Para isso, verifique o endereço IP do IoT Server VNF com o comando "osm vnf-list", e digite o seguinte Localizador de Recursos Uniforme (URL) em um navegador da Web: http://:3001, onde is o endereço IP do servidor IoT VNF. Em seguida, clique no botão sensors data collection da guia Home e verifique a atualização em tempo real dos gráficos incluídos no painel à medida que os dados são recebidos.
    NOTA: Para poder acessar a URL mencionada na etapa 4.12, o dispositivo com o navegador da Web tentando alcançar esse recurso deve estar conectado ao ecossistema NFV e ter conectividade IP com o IoT Server VNF. O serviço VPN também pode ser usado para este fim.
12. Aguarde um período de tempo adequado para obter resultados representativos da execução do serviço de agricultura inteligente. Em seguida, colete os dados armazenados no VNF do servidor IoT para análise posterior. Considerando que o sensor incluído neste experimento fornece leituras de temperatura, umidade e pressão a cada 5 segundos, o serviço no experimento é executado por um período de 10 minutos, resultando em 180 amostras de dados sentidos (60 para cada tipo de valor meteorológico).
13. Acesse o banco de dados do IoT Server VNF para recuperar os dados sentidos para análise mais aprofundada. Para isso, execute o comando "id_database=$(sudo docker ps | grep 'influxdb:' | cut -d ' ' -f 1)" no IoT Server VNF, e depois "sudo docker exec -it $id_database bash"
14. Exporte os dados para um arquivo de valor separado por csv, executando o comando "influx -influx 'mainflux' -execute "SELECT * FROM messages WHERE \"name\" = '' " formato csv > /tmp/.csv". Modifique o parâmetro para selecionar qual tipo de dados sentidos deve ser exportado com a "temperatura", "umidade" ou "pressão", e defina o parametro para escolher um nome para o arquivo de saída que manterá os resultados.
15. Salve os arquivos de dados gerados na etapa anterior para representação posterior (ver seção Resultados representativos) e verificação da operação adequada do serviço de agricultura inteligente.

Representative Results

Depois de seguir cuidadosamente o protocolo para incorporar um novo site à plataforma central e executar um serviço de rede para validar sua funcionalidade adequada, a Figura 6 mostra uma captura de tela da ferramenta de monitor de vpn aberta. Pode-se observar como o novo site está usando a VPN para todas as suas comunicações, mostrando como suas comunicações seguem a VPN para permitir essa troca de dados e, em consequência, a correta adição do novo site ao serviço VPN.

Como descrito na Figura 3,o serviço de rede está fornecendo informações de um sensor localizado em uma infraestrutura remota para o servidor localizado no local central. Além disso, a Figura 7 exibe a implantação bem-sucedida do serviço de rede a partir da GUI web osm, mostrando como o experimento pode ser devidamente instanciado na nova infraestrutura remota da pilha MANO localizada dentro do local central. Além disso, o tempo necessário no experimento para concluir a implantação do serviço é de cerca de oito minutos. Esse valor, juntamente com o tempo necessário para embarcar os descritores de serviço na plataforma de orquestração (cerca de 9 segundos, com 1,3 segundos por descritor, considerando tanto o NS quanto cada descritor VNF), permitem satisfazer o Indicador de Desempenho Chave (KPI) de 90 minutos para o tempo de criação do serviço, conforme indicado pela Parceria Público Privada de Infraestrutura^{5G 34}. Nesse contexto, o trabalho apresentado no Vidal et al.⁹ inclui uma análise aprofundada do tempo de criação do serviço com vários sites utilizando o protocolo apresentado.

A Figura 8 exibe os dados coletados do sensor, incluindo os valores de umidade, temperatura e pressão, respectivamente. Essas amostras correspondem a todos os dados enviados do sensor para um servidor remoto localizado no 5TONIC, onde esses valores são armazenados em um banco de dados. Todos esses dados demonstram que a plataforma é capaz de implantar serviços práticos de rede após a inclusão de uma nova infraestrutura, bem como para habilitar corretamente as comunicações entre os sites.

Figura 1: Distribuição do local de serviço VPN. Distribuição do serviço VPN através da plataforma e sua conectividade de link (todas passando pelo 5TONIC). Clique aqui para ver uma versão maior desta figura.

Figura 2. Visão geral do serviço de plataforma e VPN. Esta figura mostra todos os elementos da plataforma: a localização central, juntamente com sua Infraestrutura NFV, o serviço VPN e uma nova infraestrutura agregada ao sistema. Também inclui as conexões entre seus elementos. Clique aqui para ver uma versão maior desta figura.

Figura 3: Visão geral do serviço de rede. Retrata os elementos envolvidos no serviço de rede, sua distribuição e sua conectividade lógica e de rede. Clique aqui para ver uma versão maior desta figura.

Figura 4: Fluxos de trabalho do protocolo. Cada coluna representa uma seção do protocolo, onde cada ação realizada é descrita, sua conexão lógica entre eles e o componente responsável por sua execução. Clique aqui para ver uma versão maior desta figura.

Figura 5: Esquema de configuração do pino. Diagrama representando como fazer as conexões físicas entre os pinos de placa dos sensores e os pinos GPIO do SBC que incorpora esse sensor. Clique aqui para ver uma versão maior desta figura.

Figura 6: Foto do monitor OpenVPN. A imagem mostra que a infraestrutura agregada está conectada ao serviço VPN, incluindo alguns de seus detalhes sobre sua conexão. Além disso, a figura também retrata conexões adicionais pertencentes a outras infraestruturas remotas. Clique aqui para ver uma versão maior desta figura.

Figura 7: Status de implantação do OSM NS. Interface gráfica OSM, mostrando a implantação bem sucedida do serviço de rede de teste na infraestrutura remota. Clique aqui para ver uma versão maior desta figura.

Figura 8: Análise representativa dos dados coletados pelo sensor. (A) Ilustração dos dados de temperatura periodicamente coletados pelo sensor a cada 5 segundos. (B) Representação gráfica dos dados de umidade coletados pelo sensor a cada 5 segundos. (C) Retrato visual dos dados de pressão coletados pelo sensor a cada 5 segundos. Clique aqui para ver uma versão maior desta figura.

Discussion

Um dos aspectos mais importantes do protocolo descrito anteriormente é sua excelente flexibilidade para incorporar novas infraestruturas computacionais a um ecossistema NFV, independentemente de sua distribuição em termos de localização geográfica (desde que a largura de banda e latência das comunicações de rede com sites remotos o suportem). Isso é possível através de uma arquitetura de rede de sobreposição baseada em VPN, que permite o estabelecimento de um link virtual para conectar locais remotos às instalações centrais do ecossistema NFV. Essa abordagem permite a disponibilização de um canal eficaz e seguro para apoiar o NFV e as comunicações de dados entre sites de um ecossistema NFV, reduzindo a probabilidade de partes externas acessarem e/ou modificarem informações confidenciais sobre processos de orquestração NFV e dados de serviços implantados. Nesse contexto, o protocolo também descreve uma metodologia específica para compartilhar com segurança as credenciais de VPN com os sites externos que permitirão a integração de novas infraestruturas. O protocolo foi exemplificado utilizando-se o ecossistema NFV disponibilizado na 5TONIC pela Universidad Carlos III de Madrid, Telefônica e Instituto de Redes IMDEA, embora seja genérico a ser utilizado em outros ambientes NFV satisfazendo os requisitos prévios mencionados na etapa 1 deste protocolo.

Além disso, vale ressaltar a utilização exclusiva de ferramentas e softwares de código aberto para a implementação do protocolo. Não obstante as funcionalidades potencialmente benéficas que poderiam ser oferecidas por diferentes soluções proprietárias (por exemplo, Fortinet³⁵), o uso de desenvolvimentos de código aberto facilitou a integração de todos os elementos englobados pelo protocolo devido às suas características inerentes, como custo-efetividade, um amplo suporte de software fornecido pela comunidade de código aberto e um alto nível de confiabilidade, apenas para citar alguns deles. Além disso, a utilização de tecnologias de código aberto também pode promover sinergias entre componentes de natureza semelhante. Por exemplo, para monitorar o status de conexão VPN para os clientes que utilizam a plataforma, o serviço VPN implementado em todo o protocolo poderia contar com a ferramenta de monitor de vpn aberta³⁶ (uma ferramenta de monitoramento baseada em python capaz de interoperar com servidores OpenVPN).

Por outro lado, a especificação do protocolo considera a instanciação de serviços de rede em diferentes sites para fins de validação. Nesse sentido, é importante ressaltar que a implantação de serviços em um determinado local está sujeita à disponibilidade de recursos de computação, armazenamento e rede no local, bem como de equipamentos especializados que possam ser necessários para realizar a implantação (por exemplo, SEUSVs habilitados para NFV). Isso não é uma limitação do protocolo, e deve ser levado em conta pelas partes interessadas em reproduzir o experimento descrito neste artigo.

Além disso, deve-se notar que o tempo necessário para realizar a implantação de serviços de rede depende muito de diversos fatores, como o caminho de rede entre o orquestrador e os diferentes VIMs, o desempenho das comunicações de dados entre o VIM e seus nós computacionais gerenciados, e também na natureza intrínseca desses nós computacionais (não apenas por causa de seus recursos de computação disponíveis, mas também as tecnologias incorporadas para realizar a virtualização das funções de rede).

Finalmente, e dado o excelente desempenho que esta plataforma e seu serviço de VPN tiveram sobre os projetos europeus e trabalhos colaborativos onde tem sido utilizado até agora (por exemplo, 5GINFIRE, 5GRANGE ou 5GCity, mencionado na introdução deste documento), ele será considerado como um elemento importante em projetos europeus emergentes onde a Universidad Carlos III de Madrid, Participam da Telefónica e do Instituto de Redes IMDEA, como o Labirinto Horizon 2020, ou projetos nacionais, como o TRUE-5G.

Materials

Name	Company	Catalog Number	Comments
Bebop 2	Parrot		UAV used in the experiment to transport the RPis and thus, provide mobility to the compute units of external site.
BME280 Sensor	Bosch		Sensor capable of providing readings of the environmental conditions regarding temperature, barometric pressure, and humidity.
Commercial Intel Core Mini-ITX Computer	Logic Suppy		Computer server which hosts the OpenStack controller node (being executed as a VM) of the experiment's extternal aite. In addition, another unit of this equipment (along with the RPis) conforms the computational resources of the NFV insfrastrucure included in that site.
Iptables	Netfilter - Open source tool		(Software) An open source command line utility for configuring Linux kernel firewall rulset. Source-code available online: https://www.netfilter.org/projects/iptables/
Lithium Battery Pack Expansion Board. Model KY68C-UK	Kuman		Battery-power supply HAT (Hardware Attached on Top) for the UAV computation units composing the NFV infrastructure of the external site.
MacBook Pro	Apple		Commodity laptop utilized during the experiment to obtain and gather the results as described in the manuscript.
Mainflux	Mainflux Labs - Open source platform		(Software) Open source Internet of Things (IoT) platform used in the experiment for implementing the virtual network function called as IoT Server VNF. In addition, this platform includes an open-source software based on Grafana which allows the visualization and formatting of the metric data. Source code available online: https://www.mainflux.com/
Open Source MANO (OSM) - Release FOUR	ETSI OSM - Open source community		(Software) Management and Orchestration (MANO) software stack of the NFV system configured in the experiment. Source-code available online: https://osm.etsi.org/docs/user-guide/
OpenStack - Release Ocata	OpenStack - Open source community		(Software) Open source software used for setting up both the NFV infrastrucure of the central site and the NFV infrastructure of external site within the experiment. Source-code available online: https://docs.openstack.org/ocata/install-guide-ubuntu
OpenVPN - Version 2.3.10	OpenVPN - Open source community		Open source software implementing the VPN service presented in the experiment for the creation of the overlay network that will enable the operations of the NFV ecosystem (providing connectivity among all the sites comprising the ecosystem). Source-code available online: https://openvpn.net/
Openvpn-monitor	Python - Open source software		(Software) Open source program based on Python code that allows the visualization of the state of the VPN service, as well as the representation of the sites that are connected at every instant. For this purpose, the program check priodically the information provided by the VPN server implemented with OpenVPN. Source-code available online: https://github.com/furlongm/openvpn-monitor
Paho-mqtt 1.5.0	Python - Open source library		(Software) Open source library developed in Python code that enables the trasmission of the data read by the sensor through the use of MQTT standard  Source-code available online: https://pypi.org/project/paho-mqtt/
Ping	Debian - Open source tool		(Software) An open source test tool, which verifies the connectivity between two devices connected through a communications network. In addition, this tool allows to assess the network performance since it calculates the Round Trip Time (i.e., the time taken to send and received a data packet from the network).  Source-code available online: https://packages.debian.org/es/sid/iputils-ping
Power Edge R430	Dell		High-profile computer server which provides the computational capacity within the central site presented in the experiment.
Power Edge R430	Dell		High-profile computer server in charge of hosting the virtual private network (VPN) service. Note that the computing requirements for provisioning this service are high due to the resource consumption of the encryption operations present in the service.
Power Edge R630	Dell		Equipment used for hosting the virtual machine (VM) on charge of executing the MANO stack. In addition, the OpenStack controller node of the central site is also executed as a VM in this device. Note that the use of this device is not strictly needed. The operations carried out by this device could be done by a lower performance equipment due to the non-high resource specifications of the before mentioned VMs.
Raspberry PI. Model 3b	Raspberry Pi Foundation		Selected model of Single Board Computer (SBC ) used for providing the computational capacity to the experiment's external site. In addition, this SBC model is used during the deployment of the included realistic service for interpreting and sending the data collected by a sensor.
RPi.bme280 0.2.3	Python - Open source library		(Software) Open source library developed in Python code that allows to interface the sensor Bosch BME280, and interpret the readings offered by that sensor. Source-code available online: https://pypi.org/project/RPi.bme280/