Intégration d’infrastructures d’expérimentation 5G dans un écosystème NFV multisite

Summary

L’objectif du protocole décrit est de prendre en charge l’intégration flexible des infrastructures d’expérimentation 5G dans un écosystème NFV multi-sites, grâce à une architecture réseau superposée basée sur VPN. De plus, le protocole définit comment valider l’efficacité de l’intégration, y compris un déploiement de service vertical multisite avec de petits véhicules aériens compatibles NFV.

Abstract

La virtualisation des fonctions réseau (NFV) a été considérée comme l’un des principaux catalyseurs de la^5e génération de réseaux mobiles, ou 5G. Ce paradigme permet de réduire la dépendance à l’égard de matériel spécialisé pour déployer les télécommunications et les services verticaux. À cette fin, il s’appuie sur des techniques de virtualisation pour faciliter les fonctions réseau, simplifier leur développement et réduire le temps et les coûts de déploiement. Dans ce contexte, l’Universidad Carlos III de Madrid, Telefónica et l’IMDEA Networks Institute ont développé un écosystème NFV au sein de 5TONIC, un centre d’innovation de réseau ouvert axé sur les technologies 5G, permettant la création de scénarios d’expérimentation complexes et proches de la réalité à travers un ensemble distribué d’infrastructures NFV, qui peuvent être mis à disposition par les parties prenantes à différents endroits géographiques. Cet article présente le protocole qui a été défini pour incorporer de nouveaux sites NFV distants dans l’écosystème NFV multi-sites basé sur 5TONIC, décrivant les exigences pour les infrastructures existantes et nouvellement incorporées, leur connectivité via une architecture réseau superposée et les étapes nécessaires à l’inclusion de nouveaux sites. Le protocole est illustré par l’incorporation d’un site externe à l’écosystème NFV 5TONIC. Ensuite, le protocole détaille les étapes de vérification requises pour valider une intégration réussie du site. Il s’agit notamment du déploiement d’un service vertical multisite utilisant une infrastructure NFV distante avec de petits véhicules aériens sans pilote (SUAV). Cela sert à mettre en valeur le potentiel du protocole pour permettre des scénarios d’expérimentation distribués.

Introduction

L’introduction de la cinquième génération de réseaux mobiles (5G) a impliqué une révolution de l’industrie des télécommunications depuis le début de la décennie, obligeant les opérateurs de télécommunications à répondre aux spécifications beaucoup plus exigeantes des nouveaux services et applications de mise en réseau développés sous l’égide de la 5G^1,2 . Ces nouvelles spécifications incluent, sans toutefois s’y limiter, l’augmentation du débit de données, l’amélioration de la latence de transmission sans fil et la réduction des coûts d’exploitation. Parmi les technologies qui constituent les fondements des améliorations de cette nouvelle génération, network functions virtualization³ (NFV) est devenu l’un de ses principaux catalyseurs. NFV fournit la capacité de softwarize les fonctions réseau, traditionnellement relayant sur du matériel spécialisé, en utilisant plutôt des équipements physiques à usage générique, tels que des ordinateurs serveurs dans un centre de données. Avec ce nouveau paradigme, les opérateurs de télécommunications et les industries verticales peuvent déployer des fonctions et des services réseau sous la forme d’un ensemble de composants logiciels, et économiser des coûts à la fois dans le déploiement et la maintenance des services, tout en facilitant une élasticité de l’infrastructure réseau beaucoup plus élevée. Cette approche atténue ou élimine la nécessité d’utiliser des périphériques dédiés (et généralement plus complexes et moins réutilisables) pour la plupart des fonctions spécifiques au réseau et à la verticale, et prend en charge un degré d’automatisation opérationnelle beaucoup plus élevé et plus dense, réduisant ainsi les coûts de déploiement et de maintenance.

Compte tenu de tous les avantages qu’un environnement NFV est en mesure de fournir, il est naturel qu’un grand nombre d’intervenants pertinents du secteur des télécommunications aient été de plus en plus impliqués dans la mise à l’essai de nouvelles idées de services sur les environnements NFV. Dans ce contexte, Telefónica et IMDEA Networks Institute ont créé 5TONIC⁴, un laboratoire ouvert de recherche et d’innovation axé sur les technologies 5G. Basé à Madrid (Espagne), ce laboratoire dispose d’un large éventail de technologies disponibles pour les chercheurs et les partenaires afin de stimuler le développement et la validation des services 5G. En particulier, ce laboratoire dispose d’une plate-forme NFV expérimentale où les développeurs sont en mesure de déployer et de tester leurs nouvelles applications et services basés sur NFV sur un écosystème NFV conforme à l’ETSI⁵. Ainsi, des conclusions expérimentales sur les choix de conception et les propositions technologiques peuvent être tirées dans un environnement réaliste beaucoup plus flexible que les réseaux de production. Cette plate-forme a été conçue pour prendre en charge les activités d’expérimentation sur plusieurs sites externes, qui peuvent être interconnectés de manière flexible à 5TONIC à l’aide d’un protocole bien défini.

La solution technique adoptée pour l’écosystème NFV 5TONIC prend en compte l’utilisation d’un seul orchestrateur NFV, implémenté à l’aide du logiciel Open Source MANO (OSM) hébergé par ETSI^6. Il s’agit de l’élément chargé de gérer et de coordonner le cycle de vie des services réseau (NS). Ces services peuvent être construits comme une composition de réseau virtualisé / fonctions verticales (VNF), qui peut être déployée sur n’importe lequel des sites intégrés sur la plate-forme NFV. La conception de l’écosystème NFV 5TONIC a été réalisée dans le cadre du projet H2020 5GINFIRE^7,8, où la plate-forme a été utilisée pour soutenir l’exécution de plus de 25 expériences, sélectionnées dans le cadre d’un processus concurrentiel d’appel ouvert, sur huit infrastructures expérimentales verticales spécifiques situées en Europe et une au Brésil, cette dernière reliée par un lien transocéanique. En outre, la plate-forme a été exploitée pour construire un banc d’essai NFV distribué à l’échelle nationale, en Espagne, soutenant les activités d’expérimentation dans le cadre du projet espagnol 5GCity^9,10. Plus récemment, un site brésilien supplémentaire a été intégré à la plateforme, pour soutenir les activités de démonstration conjointes dans le cadre d’une coopération en matière de recherche et d’innovation établie entre le Brésil et l’Europe (c’est-à-dire le projet 5GRANGE^11,12). Enfin, l’infrastructure a été utilisée pour soutenir des expériences tierces dans le cadre du projet 5G-VINNI^13,14. La répartition géographique de la plate-forme NFV peut être vue à la figure 1.

Les organisations intéressées hébergeant leur propre infrastructure NFV peuvent se connecter de manière flexible à l’écosystème NFV 5TONIC, sous réserve de l’approbation du comité directeur 5TONIC, devenir des fournisseurs de bancs d’essai au sein de l’écosystème distribué et participer à des activités conjointes d’expérimentation et de démonstration. Pour ce faire, ils doivent disposer d’un VIM (Virtual Infrastructure Manager) conforme à la pile logicielle OSM. L’orchestrateur NFV 5TONIC est capable d’interagir avec les VIM sur les sites impliqués dans le déploiement d’un service donné, en coordonnant l’allocation et la configuration des ressources informatiques, de stockage et de réseau nécessaires à l’instanciation et à l’interconnexion des VNF qui composent un service réseau, et en contrôlant son cycle de vie, de son intégration à sa mise hors service finale.

Afin de gérer l’échange de contrôle et le trafic de données au sein de tous les sites interconnectés, l’écosystème NFV 5TONIC utilise une architecture réseau superposée basée sur des réseaux privés virtuels (VPN). Cette approche fournit un accès sécurisé basé sur PKI aux sites externes intégrés dans l’écosystème 5TONIC, permettant l’échange d’informations de contrôle NFV entre la pile logicielle OSM et les différents VIRTUAL répartis sur les bancs d’essai, ainsi que l’échange d’informations nécessaires à la gestion et à la configuration de tous les VNF. De plus, ce réseau de superposition prend en charge la diffusion du trafic de données entre les VNF déployés sur différents sites.

Dans ce contexte, le présent document détaille le protocole conçu pour intégrer un site externe à un écosystème NFV. Le protocole suppose que l’écosystème est régi par un seul orchestrateur NFV, installé sur un site central, et que les sites externes disposent d’une solution VIM compatible avec la pile logicielle orchestrator. Le protocole proposé permet d’incrémenter le portefeuille de ressources de l’écosystème expérimental, avec l’intégration flexible de sites NFV et d’infrastructures verticales spécifiques. Cela permet la création d’une plate-forme MANO distribuée capable de tester et de valider de nouveaux services réseau et verticaux sur plusieurs sites, sous le contrôle d’un seul orchestrateur NFV. Afin d’illustrer le fonctionnement interne du protocole, le processus sera illustré par l’ajout d’un site NFV externe à l’écosystème NFV 5TONIC actuel, décrivant les composants nécessaires sur le site externe et 5TONIC, ainsi que toutes les étapes à suivre pendant le processus d’intégration. La figure 2 donne un aperçu de l’objectif de l’intégration, avec le nouveau banc d’essai NFV connecté à la plate-forme 5TONIC à partir de laquelle les services réseau peuvent être déployés, au moyen de connexions VPN entre le site central et le reste des infrastructures externes.

En outre, pour démontrer l’efficacité du protocole, le déploiement d’un service vertical simple sera montré, en utilisant l’écosystème 5TONIC et un site externe avec de petits véhicules aériens sans pilote (SAV) compatibles NFV. La conception du service vertical a été inspirée par une expérience présentée dans Vidal et al.⁹, qui a été simplifiée à des fins d’illustration de cet article. La figure 3 décrit le service, qui vise à aider les activités agricoles intelligentes dans une région éloignée. Le service considère un fournisseur de services agricoles intelligents qui utilise des SAV pour collecter et diffuser les données produites par des capteurs météorologiques dispersés sur un champ de culture. Par souci de simplicité, l’expérience présentée dans l’article considère un seul SUAV et un capteur, capables de fournir des mesures de température, d’humidité et de pression. Dans l’expérience, le site NFV externe héberge un point d’accès Wi-Fi déployé en tant que VNF sur le SUAV. Ce VNF offre une connectivité d’accès réseau au capteur, transférant les données détectées vers une fonction de passerelle. Ce dernier est déployé en tant que VNF sur un équipement au sol (un ordinateur mini-ITX). La diffusion des données du capteur vers la fonction passerelle suit une approche Publish/Subscribe basée sur le protocole MQTT (Message Queuing Telemetry Transport)¹⁵. La fonction passerelle traite puis diffuse les données vers un serveur Internet des objets (IoT), qui est mis à disposition en tant que VNF sur le site central de l’écosystème NFV, sur la base de la plate-forme open source Mainflux^16. Enfin, le scénario suppose une zone éloignée où la connectivité Internet est fournie par un réseau d’accès cellulaire non 3GPP. Par conséquent, le service comprend deux VNF supplémentaires: 1) un routeur d’accès VNF, qui implémente la pile de protocoles du plan utilisateur d’un équipement utilisateur 3GPP connecté à un réseau d’accès non 3GPP^17; et 2) une mise en œuvre de base d’un réseau central 5G, prenant en charge la transmission d’informations entre le routeur d’accès et les VNF du serveur IoT. À cette fin, le VNF de base 5G fournit une implémentation simplifiée du plan utilisateur d’une fonction d’interfonctionnement non 3GPP et d’une fonction de plan utilisateur, telle que définie par 3GPP¹⁷.

Enfin, la figure 4 représente les processus les plus pertinents impliqués lors de l’élaboration du protocole, en mettant en évidence leurs interconnexions logiques et les entités chargées de leur exécution.

Protocol

1. Mise à disposition du site central de l’écosystème NFV (conditions préalables de l’expérience)

1. Allouez un espace d’adressage IP à utiliser par le site central. Pour les besoins de ce protocole, l’espace d’adressage privé 10.4.0.0/16 sera utilisé.
2. Installez la pile logicielle MANO (Management and Orchestration) sur le site central. En particulier, l’expérience menée tout au long de ce protocole utilise l’Open Source MANO (OSM) Release SEVEN¹⁸, qui nécessite les ressources suivantes: Ubuntu 18.04 comme système d’exploitation, 2 unités centrales de traitement (CPU), 8 Go de mémoire vive (RAM), 40 Go de disque dur et au moins une interface réseau avec accès Internet. Pour l’installation, suivez les instructions disponibles dans la documentation OSM Release SEVEN¹⁸.
3. Configurez un Virtual Infrastructure Manager (VIM) compatible avec OSM dans le site central. Plus précisément, l’expérience utilise la version OpenStack Ocata²⁰, fonctionnant sur une machine virtuelle (VM) avec Ubuntu 16.04, 4 processeurs, 16 Go de RAM et 200 Go de disque dur. L’infrastructure NFV (NFVI) gérée par ce VIM comprend trois ordinateurs serveurs, chacun avec Ubuntu 16.04, 8 processeurs, 32 Go de RAM et 2 To de stockage. Pour l’installation, suivez la documentation de la version²¹d’Ocata.
   1. Déployez un réseau virtuel au sein de la plate-forme cloud OpenStack, à l’aide d’une plage d’adresses IP à partir de l’espace d’adressage alloué à l’étape 1.1. Ce réseau, désormais appelé réseau de gestion, sera utilisé pour prendre en charge l’échange d’informations d’orchestration NFV entre l’OSM et les fonctions de réseau virtuel (VNF) instanciées sur le site central.
   2. Configurez un réseau virtuel (désormais appelé réseau de données) pour prendre en charge les communications de données intersites, entre les VNF du site central et d’autres VNF exécutés sur des sites externes. À cette fin, utilisez une plage d’adresses IP à partir de l’espace d’adressage de l’étape 1.1.
      REMARQUE: La mise en œuvre des réseaux mentionnés dans les étapes 1.3.1 et 1.3.2 a été effectuée à l’aide de réseaux de fournisseurs d’OpenStack. Les réseaux des fournisseurs doivent être connectés à l’infrastructure réseau physique du site central pour garantir un fonctionnement approprié.
4. Connectez les réseaux privés virtuels (c’est-à-dire les réseaux de gestion et de données), ainsi que les machines VIM et OSM, à un équipement offrant des fonctionnalités de routage en périphérie. Ce routeur servira de point d’entrée vers le site central de l’écosystème NFV.
5. Mettre à disposition un référentiel d’expérience public pour fournir tout le contenu nécessaire à la réalisation de l’expérience. En particulier, ce protocole utilise le référentiel public ಲ.

2. Configuration du service de réseau privé virtuel

1. Allouer un espace d’adressage IP pour prendre en charge le fonctionnement approprié de l’écosystème multisite, afin que les communications réseau puissent être établies efficacement entre plusieurs sites.
   REMARQUE: Pour permettre des communications réseau efficaces entre plusieurs sites, il faut concevoir soigneusement l’espace d’adressage IP à utiliser par l’écosystème NFV, ainsi que par les sites externes qui doivent s’y connecter. En particulier, l’espace d’adressage alloué aux communications intersites ne devrait pas entrer en collision avec l’espace d’adressage déjà utilisé sur tous les autres sites à d’autres fins.
   1. Allouez un espace d’adressage IP à utiliser par des sites externes. Les adresses de ce bloc seront attribuées aux entités NFV (par exemple, les VIM) et aux VNF du site externe. Pour illustrer ce protocole, l’espace d’adressage privé 10.154.0.0/16 sera utilisé.
   2. Allouez un espace d’adressage IP aux liens virtuels entre les sites externes et l’écosystème NFV. Ces liens virtuels seront pris en charge par un service VPN. Pour illustrer ce protocole, la plage d’adresses 10.154.254.0/24 sera utilisée pour ces liens virtuels.
2. Configurez un équipement pour fournir le service de réseau privé virtuel (VPN) (c’est-à-dire un serveur VPN). En particulier, l’expérience utilise un ordinateur serveur avec Ubuntu 16.04 (image variante 64 bits), six processeurs indépendants, 16 Go de RAM, 1 To de disque de stockage et deux interfaces réseau.
   1. Configurez l’une des interfaces réseau du serveur VPN pour permettre la réception des demandes de connexion provenant de sites externes via Internet. À cette fin, il est nécessaire d’utiliser une interface du serveur configurée avec une adresse IP publique.
   2. Configurez le lien entre le serveur VPN et le routeur périphérique du site central. Dans l’expérience, ce lien a été attribué la plage d’adresses 10.4.255.0/24. Configurez les itinéraires réseau appropriés sur le serveur VPN, afin que l’écosystème NFV devienne accessible à partir de sites externes connectés au service VPN.
3. Installez le logiciel open source VPN fourni par le projet OpenVPN²³ dans le serveur VPN. Plus précisément, cette expérience utilise la version 2.3.10 d’OpenVPN, et son déploiement a été effectué avec le script bash « openvpn-install.sh », disponible à http://github.com/Nyr/openvpn-install (d’autres options d’installation sont décrites dans la documentation OpenVPN ²⁴). Le script bash présente les paramètres alternatifs qui entraîneront la configuration du service VPN.
   1. Sélectionnez l’adresse IP pour écouter les demandes de connexion VPN (c’est-à-dire l’adresse IP publique).
   2. Décidez quel protocole (UDP ou TCP) doit être utilisé pour piloter les communications via le VPN. Dans ce cas, l’expérience s’appuie sur UDP qui est le protocole recommandé.
   3. Spécifiez le port qui comprendra le duple (ainsi que l’adresse IP publique) qui sera utilisé pour recevoir les demandes de connexion au service. Par défaut, la valeur attribuée est 1194.
   4. Choisissez l’un des serveurs DNS de la liste demandé par l’assistant qui gérera les demandes de résolution de noms effectuées par les clients du service VPN.
   5. Appuyez sur n’importe quelle touche pour activer le lancement automatique du processus d’installation du service VPN.
4. Modifiez le fichier de configuration « server.conf » qui se trouve sous le répertoire « /etc/openvpn/server/ » et incluez la directive « client-to-client » visant à étendre la configuration de base fournie par l’étape 2.3. Ainsi, différents clients connectés au service VPN pourront se joindre.
5. Activez la configuration du client individuel dans la configuration VPN pour pouvoir gérer indépendamment les affectations de routage pour chaque client.
   1. Ajoutez la directive « client-config-dir ccd », en modifiant le même fichier de configuration qu’à l’étape 2.4.
   2. Créez le répertoire « ccd » à l’aide de la commande « mkdir /etc/openvpn/ccd/ ». Ce répertoire servira lors de la section suivante du protocole à placer les fichiers comprenant les directives de routage associées aux clients destinés à être intégrés dans la plateforme.
6. Configurez les règles de pare-feu nécessaires pour autoriser les connexions avec le service, tout en protégeant le serveur VPN contre les attaques malveillantes. À cette fin, cette expérience s’appuie sur iptables²⁵, qui est un utilitaire de ligne de commande développé pour configurer le pare-feu du noyau Linux.
   1. Tout d’abord, bloquez le trafic entrant vers le serveur VPN avec la commande « iptables -P INPUT DROP ».
   2. Autoriser la réception des demandes de connexion VPN avec les commandes « iptables -A INPUT -i -m state --state NEW -p udp --dport 1194 -j ACCEPT » ( est le nom de l’interface du serveur VPN avec l’adresse IP publique) et « iptables -A INPUT -i tun+ -j ACCEPT ».
   3. Autoriser le transfert de trafic entre les interfaces du serveur VPN (c’est-à-dire l’interface publique et l’interface virtuelle créée par le service VPN appelé tun0), pour permettre au serveur VPN de traiter la demande de connexion au service. À cette fin, exécutez la commande « iptables -A FORWARD -i tun+ -o -m state --state RELATED,ESTABLISHED -j ACCEPT && iptables -A FORWARD -i -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT ».
   4. Permettre au serveur VPN de fournir la capacité de traduction d’adresses réseau (NAT) dans le but de fournir un accès Internet au site central, en exécutant: « iptables -t nat -A POSTROUTING -s 10.4.0.0/16 -o -j MASQUERADE && iptables -A OUTPUT -o tun+ -j ACCEPT ».

3. Intégration d’un site NFV externe

1. Obtenez une plage d’adresses IP appropriée pour intégrer le site dans l’écosystème NFV. Cette plage d’adresses sera fournie par le centre d’opérations réseau de l’écosystème NFV. Selon l’étape 2.1.1 de ce protocole, l’expérience utilisera une plage d’adresses IP pour le site externe dans la version 10.154.0.0/16.
2. Créez et fournissez les informations d’identification de sécurité pour vous connecter à l’écosystème NFV.
   1. Générez des informations d’identification VPN qui permettront à la nouvelle infrastructure d’établir une connexion sécurisée avec le serveur VPN. À cette fin, exécutez la commande « bash openvpn-install.sh » dans le serveur VPN, sélectionnez l’option « 1) Ajouter un nouveau client » de la liste demandée et fournissez le nom à associer à ces informations d’identification, par exemple, uc3m_infrastructure. Cette étape générera un fichier avec les informations d’identification VPN (nommé " uc3m_infrastructure.ovpn » dans l’exemple).
   2. Créez un fichier texte dans le répertoire « /etc/openvpn/ccd/ » du serveur VPN, y compris les directives de routage (comme spécifié dans la documentation OpenVPN ²⁴) qui doivent être poussées par le serveur VPN chaque fois qu’une connexion au service VPN est établie à l’aide des informations d’identification VPN.
      REMARQUE : Le nom du fichier texte doit correspondre au nom spécifié lors de la création des informations d’identification VPN (par exemple, uc3m_infrastructure) pour fournir une configuration personnalisée pour chaque client VPN.
   3. Fournissez le fichier d’informations d’identification VPN au personnel technique du site externe. Cela doit se faire via un canal sécurisé et fiable. Dans cette expérience, un processus de cryptage manuel est utilisé. Pour chiffrer les informations d’identification VPN, exécutez la commande « 7za a -tzip '-p' -mem=AES256  », en définissant comme clé de chiffrement souhaitée, comme nom choisi pour le fichier chiffré, et comme le nom de fichier du fichier d’informations d’identification VPN (par exemple, uc3m_infrastructure.ovpn).
   4. Fournissez les informations d’identification cryptées au personnel technique du nouveau site, ainsi que la clé qui permet les procédures de déchiffrement, via un canal de communication sécurisé.
      REMARQUE: Dans cette expérience, les informations d’identification cryptées ont été fournies par courrier électronique, tandis que la clé de décryptage a été envoyée via un canal séparé, en utilisant le service de messages courts (SMS), avec un accord hors ligne du numéro de téléphone.
3. Configurer l’environnement sur le nouveau site, de manière à établir la connexion avec l’écosystème NFV, et à permettre que le NFVI distant soit attaché à la pile OSM du site central.
   1. Installez le logiciel VPN fourni par OpenVPN²⁴ sur un ordinateur, pour permettre un lien virtuel entre le site externe et le site central de l’écosystème NFV. L’ordinateur avec le logiciel OpenVPN servira de client VPN ou de point de terminaison VPN sur le site externe. Le lien virtuel sera réalisé au moyen d’un tunnel VPN protégé entre le point de terminaison VPN et le serveur VPN. Dans l’expérience, le point de terminaison VPN s’exécute sur un ordinateur serveur avec Ubuntu 18.04, 8 processeurs, 8 Go de RAM, 128 Go de disque de stockage et 3 interfaces GbE (une pour se connecter au service VPN via Internet).
   2. Activez le transfert IP dans le point de terminaison VPN pour prendre en charge les fonctionnalités de routage réseau. À cette fin, incluez la ligne « net.ipv4.ip_forward=1 » dans le fichier de configuration système situé dans le chemin « /etc/sysctl.conf » et chargez la configuration mise à jour avec la commande « sudo sysctl -p ».
   3. Déchiffrez le fichier d’informations d’identification VPN avec les informations reçues à l’étape 3.2.4, à l’aide de la commande « 7za e crypté », où le est le nom de fichier des informations d’identification VPN cryptées. Spécifiez la clé de déchiffrement lorsque la commande vous y invite.
   4. Démarrez le logiciel OpenVPN avec le fichier d’informations d’identification déchiffré à l’aide de la commande « sudo openvpn --config  » ( est le nom de fichier des informations d’identification VPN). Avec cela, le point de terminaison VPN s’authentifiera auprès du serveur VPN et recevra automatiquement les paramètres de configuration VPN et les itinéraires réseau appropriés. De cette façon, le point de terminaison VPN se comportera comme un routeur de périphérie avec un lien virtuel vers le site central de l’écosystème NFV.
   5. Vérifiez le bon fonctionnement du point de terminaison VPN à l’aide de la commande ping pour vérifier la disponibilité de la connectivité à l’un des nœuds du site central (par exemple, l’équipement de pile OSM).
   6. Dans le nouveau site, sélectionnez un VIM compatible OSM pour autoriser les opérations avec la plate-forme MANO. Pour cette expérience, la version OpenStack Ocata est utilisée.
      REMARQUE : OSM Release SEVEN prend en charge les gestionnaires d’infrastructure virtuelle suivants : OpenStack, OpenVIM^26,vCloud Director²⁷de VMware, Amazon Web Service^28,Microsoft Azure²⁹et Eclipse fog05³⁰ (voir la documentation OSM¹⁸ pour plus de détails de configuration spécifiques).
   7. Installez la version Ocata²⁰ d’OpenStack (voir les procédures détaillées dans la documentation de la version²¹).
   8. Déployez l’infrastructure NFV sur le site externe et attachez-la au VIM. En particulier, cette expérience utilise une infrastructure NFV comprenant trois ordinateurs monocarte (SBC), chacun avec une capacité de calcul de 1 Go de RAM, 4 processeurs et 32 Go de disque de stockage; et un seul ordinateur mini-ITX avec 8 processeurs, 8 Go de RAM et 128 Go pour le stockage.
      REMARQUE: Le site externe illustré dans ce protocole est basé sur une infrastructure NFV de petits véhicules aériens sans pilote (SUAV) compatibles NFV. Les détails suivis pour permettre une telle infrastructure sont fournis dans Nogales et al³¹. Les étapes 3.3.6 à 3.3.8 sont facultatives, car une infrastructure NFV peut déjà exister sur le site externe.
   9. Créez un projet OpenStack pour spécifier l’ensemble des ressources de calcul du site externe qui seront intégrées dans l’écosystème NFV. Pour ce faire, accédez à l’interface utilisateur graphique (GUI) fournie par OpenStack, connectez-vous au système avec les informations d’identification de l’administrateur, cliquez sur le bouton + Créer un projet de l’onglet Identité -> Projets et créez un projet en remplissant le formulaire affiché avec les informations demandées.
   10. Créez un utilisateur valide qui gérera le projet créé à l’étape précédente. À cette fin, accédez à l’onglet Identité -> Utilisateurs avec le même identifiant qu’à l’étape précédente, cliquez sur + Créer un utilisateur et remplissez les champs obligatoires du formulaire affiché (nom d’utilisateur et mot de passe), sélectionnez le nouveau projet créé comme projet principal et choisissez le rôle d’administrateur.
   11. Modifiez les règles de sécurité pour autoriser les autorisations de communication VNF dans le nouveau site (en particulier, activer le trafic SSH et ICMP). À cette fin, accédez à l’interface graphique OpenStack avec les informations d’identification de l’utilisateur créées à l’étape précédente, suivez la séquence : Projet -> Réseau -> Groupes de sécurité -> + Ajouter une règle, et sélectionnez l’option SSH de la liste déroulante Règle. Répétez le processus, mais en sélectionnant l’option Tous les ICMP incluse dans le menu déroulant.
   12. Téléchargez les images d’un service d’essai offert par la communauté OSM, le service réseau Ping Pong (« Fedora-x86_64-20-20131211.1-sda-ping » et « Fedora-x86_64-20-20131211.1-sda-pong ») à partir du référentiel public d’expériences, et téléchargez-les sur le VIM du site externe. Pour ce faire, suivez la séquence Projet -> Calculer -> Images -> + Créer une image, et créez les images en utilisant le formulaire affiché et en sélectionnant chacune des images.
   13. Attribuez deux plages d’adresses IP dans l’espace d’adressage du site externe (alloué à l’étape 3.1). Ces plages seront utilisées pour soutenir la gestion des VNF du site externe et pour permettre la communication de données entre les VNF, respectivement.
   14. Créez un réseau fournisseur(control-provider)à l’aide du VIM. Ce réseau prendra en charge les communications NFV entre la pile OSM sur le site central et les VNF déployés sur le nouveau site à des fins de gestion. Ce type de communication permettra également à la pile OSM de configurer des VNF après leur déploiement. Pour créer un réseau fournisseur dans OpenStack, suivez la séquence Admin -> System -> Networks -> + Create Network et remplissez les détails du nouveau réseau, en utilisant la plage d’adresses IP sélectionnée à l’étape précédente.
   15. Créez un deuxième réseau de fournisseurs(fournisseur de données)à l’aide du VIM. Ce réseau prendra en charge les communications de données entre les VNF du site et les autres VNF de l’écosystème NFV. Pour créer ce réseau de fournisseurs dans OpenStack, suivez la séquence Admin -> System -> Networks -> + Create Network, et remplissez les détails du nouveau réseau à l’aide de la plage d’adresses attribuée.
       REMARQUE : Les instructions sur la création de réseaux virtuels varient en fonction du logiciel VIM. Consultez leur documentation logicielle respective pour plus de détails.
   16. Partager les informations relatives au VIM (en particulier, le nom d’utilisateur/mot de passe et le projet créé aux étapes 3.3.9 et 3.3.10) avec le personnel technique du site central, afin de permettre l’attachement du VIM à la pile logicielle OSM.
4. Connectez l’infrastructure NFV externe à la pile logicielle OSM du site central, en utilisant les informations obtenues à partir de l’étape 3.3.16.
   1. Vérifiez la connectivité entre la pile OSM du site central et le VIM du nouveau site, à l’aide de l’outil ping.
   2. Si le test de connectivité précédent réussit, attachez le VIM externe à la pile OSM du site central. Pour ce faire, utilisez la commande suivante dans la machine OSM : « osm vim-create --name --user --password --auth_url --tenant --account_type ». Dans cette commande : est le nom sélectionné pour identifier le VIM dans la pile OSM, est le nom de l’utilisateur autorisé à gérer les ressources du site externe (voir étape 3.3.10), < MOT DE PASSE-UTILISATEUR-VIM>est le mot de passe de l’utilisateur indiqué, est le lien vers l’API mis à disposition par le VIM pour activer les requêtes de la pile OSM , est le nom du projet défini à l’étape 3.3.9, et est le logiciel VIM utilisé (dans cette expérience, OpenStack).
5. Vérifiez l’attachement approprié du nouveau VIM à la pile OSM de l’écosystème NFV.
   1. Exécutez la commande « ro_id=$(docker ps | osm_ro | grep cut -d ' ' -f 1) » pour identifier l’ID du conteneur implémentant le module Resource Orchestrator (RO) dans le système OSM. Ce module est responsable de l’interaction avec les VIM afin de coordonner et d’allouer les ressources nécessaires au déploiement des services réseau ultérieurs.
   2. Accédez au conteneur RO à l’aide de la commande « docker exec -it $ro_id bash ». Cette commande utilise l’identificateur obtenu lors de l’exécution de l’étape précédente.
   3. Vérifiez que le nouveau VIM est inclus dans la liste des centres de données disponibles, à l’aide de la commande « openmano datacenter-list ». Le nouveau site doit apparaître dans la liste avec le même nom que celui précédemment introduit à l’étape 3.4.2 avec le paramètre externe.
   4. Répertoriez les images qui ont été téléchargées sur le VIM du site externe, à l’aide de la commande « openmano vim-image-list --datacenter  ». Le paramètre indique le nom sélectionné pour identifier le VIM dans la pile OSM. Si l’exécution de cette commande réussit, la connectivité avec le VIM externe a été établie avec succès. Vérifiez que les images ping-pong sont incluses dans la liste.
   5. Répertoriez les réseaux disponibles sur le nouveau site avec la commande « openmano vim-net-list --datacenter  ». Vérifiez que le fournisseur de contrôle et le fournisseur de données sont présents.
6. Effectuer une validation préliminaire de la bonne intégration du nouveau site, en utilisant un service d’essai offert par la communauté OSM (tout le contenu à cet égard est inclus dans le référentiel d’expériences). À cette fin, les commandes incluses dans les étapes suivantes seront exécutées dans l’équipement hébergeant la pile OSM.
   1. Intégrez les descripteurs VNF (VNFD) à la pile OSM en exécutant la commande « osm vnfd-create » pour chacun des VNF composant le service d’évaluation ( correspond au nom de fichier du package VNFD).
   2. Intégrez le descripteur NS (NSD) du service d’évaluation avec la commande « osm nsd-create », où indique le nom de fichier du package NSD (dans cette expérience, ping_pong_ns.tar.gz) ».
   3. Démarrez l’instanciation du service réseau Ping Pong (NS) sur les sites externes et centraux, en utilisant la commande « osm ns-create --ns_name --nsd_name ping_pong_ns --vim_account --config '{vnf: [{member-vnf-index: '2', vim_account: }]}' ». Le paramètre identifie le VIM du site externe dans la pile OSM. L’option « --config » indique que tous les VNF composant le service doivent être déployés sur le site externe géré par ce VIM, à l’exception du VNF identifié par l’index 2 dans le NS, qui sera déployé dans le site central (le VIM du site central est spécifié dans le paramètre).
   4. Vérifiez que le NS a été déployé et son état à l’aide de la commande « osm ns-list ». Si l’instanciation réussit, le statut passera à « PRÊT ».
   5. Vérifiez l’adresse IP de chacun des deux VNF avec « osm vnf-list » (nécessaire pour vous connecter aux machines par la suite).
   6. Connectez-vous à chaque VNF via SSH, à l’aide de la commande « ssh fedora@ » ( représente l’adresse IP du VNF auquel se connecter, obtenue à l’étape précédente). Introduisez le mot de passe « fedora » lorsque SSH vous y invite. Une fois connectés aux deux machines, vérifiez leurs interfaces à l’aide de la commande « ip address show », et obtenez les adresses IP sur leurs interfaces connectées au réseau du fournisseur de données (interface eth1 dans les deux VNF). À partir de l’un des VNF, effectuez un ping sur l’autre VNF, en utilisant l’adresse IP distante dans le réseau du fournisseur de données. S’il y a une connectivité, le test de validation préliminaire sera considéré comme réussi.

4. Validation de la plateforme multi-sites NFV avec un service vertical réaliste

1. Téléchargez les images VNF à partir du référentiel public et téléchargez-les dans le VIM de leur site correspondant (voir Figure 3), en suivant la procédure détaillée à l’étape 3.3.12. En particulier, le site externe hébergera le VNF du point d’accès, le VNF du routeur, le VNF de la passerelle MQTT et le VNF du routeur d’accès. Le site central hébergera le VNF 5G Core et le VNF IoT Server.
2. Intégrez les VNFD et le NSD du service d’agriculture intelligente à la pile OSM (tous les descripteurs peuvent être téléchargés à partir du référentiel d’expériences).
   1. Intégrez les VNFD à la pile OSM en exécutant la commande « osm vnfd-create  », pour chacun des VNF du service réseau. Dans ce cas, le parameter correspond au nom de fichier du package VNFD.
   2. Intégrez le NSD à la pile OSM avec la commande « osm nsd-create  », où indique le nom de fichier du package NSD (dans cette expérience, jove_uavs_scenario_nsd.tar.gz).
3. Déployez le service réseau d’agriculture intelligente. Pour ce faire, exécutez la commande suivante à partir de l’interface de ligne de commande OSM : osm ns-create --ns_name --nsd_name jove_uavs_scenario_nsd --vim_account --config '{vnf: [ {member-vnf-index: « 5 », vim_account: }, {member-vnf-index: « 6 », vim_account: } ], wim_account: False }'.
   REMARQUE : Comme indiqué à l’étape 3.6.3., les paramètres et central indiquent les sites où les VNF doivent être déployés. En particulier, tous les VNF composant le service d’agriculture intelligente seront placés dans le nouveau site externe, à l’exception de ceux avec les index 5 et 6 (le 5G Core et le serveur IoT VNF)qui seront alloués au site central.
4. Vérifiez que le NS a été déployé, en suivant la même procédure qu’à l’étape 3.6.4.
5. Accès au serveur IoT VNF avec la commande « ssh mosquittosubscriber@ » et vérifiez son interface configurée pour communiquer avec MQTT Gateway VNF via la commande « ip address show dev eth1 ». L’adresse IP du VNF () peut être obtenue en exécutant la « osm vnf-list » dans la ligne de commande OSM.
6. En suivant une procédure analogue, accédez au VNF de passerelle MQTTet exécutez la commande « sudo python3 publisher_MQTT_GW.py -ma -ba  » où le est obtenu à l’étape précédente et le exécutant la commande « ip address show dev eth1 » dans le VNF de passerelle MQTT. Cette étape initialise le VNF de passerelle MQTT, qui recevra les données générées par le capteur à l’aide de la norme MQTT¹⁵, transmettant ces données au serveur IoT VNF en utilisant la même norme.
7. Préparez un ordinateur monocarte (SBC) fixant un capteur météorologique et doté de la capacité de l’émetteur-récepteur pour transmettre les lectures du capteur vers le VNF de la passerelle MQTT.
   REMARQUE: Pour illustrer ce protocole, un modèle SBC en particulier a été utilisé. Par conséquent, les étapes suivantes peuvent devoir être adaptées en cas d’utilisation d’une plate-forme SBC différente.
   1. Connectez (par exemple, à l’aide de fils de cuivre soudés à l’étain) les broches de la carte du capteur aux broches d’entrée/sortie à usage général (GPIO) du SBC, en suivant le schéma de configuration de la figure 5.
   2. Activez le module noyau I2C dans le SBC pour pouvoir vérifier si le capteur est détecté. Pour ce faire, exécutez la commande « sudo raspi-config », suivez la séquence Options d’interfaçage -> I2C -> Oui dans le menu affiché, et redémarrez le SBC pour rendre les modifications effectives.
   3. Vérifiez que le capteur est détecté Installation du logiciel i2c-tools dans le SBC et exécution de la commande « sudo i2cdetect -y 1 ». Si c’est le cas, une grille devrait apparaître indiquant la position où le capteur est détecté.
   4. Installez les bibliothèques logicielles appropriées pour permettre au SBC de lire et d’envoyer les données fournies par le capteur. En particulier, cette expérience s’appuie sur les bibliothèques Python RPi.bme280³² et paho-mqtt^33.
8. À l’aide de l’application mobile du SUAV, décollez le véhicule aérien qui héberge le point d’accès VNFet positionnez-le pour fournir une couverture sans fil au SBC avec le capteur.
   REMARQUE: Le vol des SAV compatibles NFV est indépendant du comportement opérationnel du service réseau, qui est capable de fonctionner que les SAV volent ou soient en état de repos pour atténuer la consommation de la batterie. Ainsi, l’étape 4.8 est facultative.
9. Connectez le SBC chargé de lire les données collectées par le capteur au point d’accès sans fil Wi-Fi fourni par le point d’accès VNF). Après une pièce jointe réussie, un chemin réseau sans fil sera activé du capteur vers le VNF de la passerelle MQTT.
10. Démarrez la transmission des données détectées, en exécutant la commande « python3 /home/ubuntu/sensorDataTransmission.py -a  » dans le SBC qui incorpore le capteur ( est l’adresse IP obtenue à l’étape 4.6.).
11. Accédez à l’interface graphique Web fournie par le serveur IoT VNF pour vérifier la réception correcte en temps réel des données détectées. À cette fin, vérifiez l’adresse IP du VNF IoT Server avec la commande « osm vnf-list » et tapez l’URL (Uniform Resource Locator) suivante dans un navigateur Web : http://:3001, où est l’adresse IP du serveur IoT VNF. Ensuite, cliquez sur le bouton Collecte de données des capteurs de l’onglet Accueil et vérifiez la mise à jour en temps réel des graphiques inclus dans le tableau de bord au fur et à mesure que les données sont reçues.
    REMARQUE: Pour pouvoir accéder à l’URL mentionnée à l’étape 4.12, l’appareil avec le navigateur Web qui tente d’atteindre cette ressource doit être connecté à l’écosystème NFV et disposer d’une connectivité IP avec le VNF IoT Server. Le service VPN peut également être utilisé à cette fin.
12. Attendez une période de temps appropriée pour obtenir des résultats représentatifs de l’exécution du service d’agriculture intelligente. Ensuite, collectez les données stockées dans le serveur IoT VNF pour une analyse plus approfondie. Étant donné que le capteur inclus dans cette expérience fournit des lectures de température, d’humidité et de pression toutes les 5 secondes, le service de l’expérience dure une période de 10 minutes, ce qui donne 180 échantillons de données détectées (60 pour chaque type de valeur météorologique).
13. Accédez à la base de données du VNF IoT Server pour récupérer les données détectées pour une analyse plus approfondie. À cette fin, exécutez la commande « id_database=$(sudo docker ps | grep 'influxdb:' | cut -d ' ' -f 1) » sur le VNF Du serveur IoT, puis « sudo docker exec -it $id_database bash »
14. Exportez les données dans un fichier CSV (valeurs séparées par des virgules), en exécutant la commande « influx -database 'mainflux' -execute « SELECT * FROM messages WHERE \"name\ » = '' « -format csv > /tmp/.csv ». Modifiez le paramètre pour sélectionner le type de données détectées à exporter avec la « température », « humidité » ou « pression », et définissez le paramètre pour choisir un nom pour le fichier de sortie qui conservera les résultats.
15. Enregistrez les fichiers de données générés à l’étape précédente pour une représentation ultérieure (voir la section Résultats représentatifs) et la vérification du bon fonctionnement du service d’agriculture intelligente.

Representative Results

Après avoir suivi attentivement le protocole pour incorporer un nouveau site à la plate-forme centrale et exécuter un service réseau pour valider son bon fonctionnement, la figure 6 illustre une capture d’écran de l’outil open-vpn-monitor. On peut observer comment le nouveau site utilise le VPN pour toutes ses communications, montrant comment ses communications suivent le VPN pour permettre cet échange de données et, par conséquent, l’ajout correct du nouveau site au service VPN.

Comme illustré à la figure 3,le service réseau transmet des informations à partir d’un capteur situé dans une infrastructure distante vers le serveur situé dans le site central. En outre, la figure 7 illustre le déploiement réussi du service réseau à partir de l’interface graphique Web OSM, montrant comment l’expérience peut être correctement instanciée dans la nouvelle infrastructure distante à partir de la pile MANO située dans le site central. De plus, le temps nécessaire à l’expérience pour terminer le déploiement du service est d’environ huit minutes. Cette valeur, ainsi que le temps nécessaire pour intégrer les descripteurs de service dans la plate-forme d’orchestration (environ 9 secondes, avec 1,3 seconde par descripteur, en tenant compte à la fois du NS et de chaque descripteur VNF), permettent de satisfaire à l’indicateur de performance clé (KPI) de 90 minutes pour le temps de création du service, comme indiqué par le partenariat public-privé d’infrastructure 5G³⁴. Dans ce contexte, les travaux présentés dans Vidal et al.⁹ comprennent une analyse approfondie du temps de création du service avec plusieurs sites utilisant le protocole présenté.

La figure 8 montre les données collectées à partir du capteur, y compris les valeurs d’humidité, de température et de pression respectivement. Ces échantillons correspondent à toutes les données envoyées par le capteur à un serveur distant situé dans 5TONIC, où ces valeurs sont stockées dans une base de données. Toutes ces données démontrent que la plate-forme est capable de déployer des services réseau pratiques après l’inclusion d’une nouvelle infrastructure, ainsi que de permettre correctement les communications entre les sites.

Figure 1: Distribution du site de service VPN. Distribution du service VPN via la plateforme et leur connectivité de liaison (tous passant par 5TONIC). Veuillez cliquer ici pour voir une version agrandie de cette figure.

Graphique 2. Vue d’ensemble de la plateforme et du service VPN. Cette figure montre tous les éléments de la plate-forme: l’emplacement central, ainsi que son infrastructure NFV, le service VPN et une nouvelle infrastructure agrégée au système. Il comprend également les connexions entre ses éléments. Veuillez cliquer ici pour voir une version agrandie de cette figure.

Figure 3: Vue d’ensemble du service réseau. Il décrit les éléments impliqués dans le service réseau, sa distribution et sa connectivité logique et de mise en réseau. Veuillez cliquer ici pour voir une version agrandie de cette figure.

Figure 4: Workflows de protocole. Chaque colonne représente une section du protocole, où chaque action effectuée est décrite, sa connexion logique entre eux et le composant en charge de son exécution. Veuillez cliquer ici pour voir une version agrandie de cette figure.

Figure 5: Schéma de configuration des broches. Diagramme représentant comment établir les connexions physiques entre les broches de carte des capteurs et les broches GPIO du SBC qui incorpore ce capteur. Veuillez cliquer ici pour voir une version agrandie de cette figure.

Figure 6: Instantané du moniteur OpenVPN. L’image montre que l’infrastructure agrégée est connectée au service VPN, y compris certains de ses détails concernant sa connexion. En outre, la figure représente également des connexions supplémentaires appartenant à d’autres infrastructures distantes. Veuillez cliquer ici pour voir une version agrandie de cette figure.

Figure 7: État du déploiement d’OSM NS. Interface graphique OSM, montrant le déploiement réussi du service réseau de test dans l’infrastructure distante. Veuillez cliquer ici pour voir une version agrandie de cette figure.

Figure 8: Analyse représentative des données collectées par le capteur. (A) Illustration des données de température collectées périodiquement par le capteur toutes les 5 secondes. (B) Représentation graphique des données d’humidité collectées par le capteur toutes les 5 secondes. (C) Représentation visuelle des données de pression collectées par le capteur toutes les 5 secondes. Veuillez cliquer ici pour voir une version agrandie de cette figure.

Discussion

L’un des aspects les plus importants du protocole décrit précédemment est sa flexibilité exceptionnelle pour intégrer de nouvelles infrastructures de calcul à un écosystème NFV, quelle que soit leur distribution en termes de situation géographique (tant que la bande passante et la latence des communications réseau avec les sites distants le prennent en charge). Cela est possible grâce à une architecture réseau superposée basée sur VPN, qui permet l’établissement d’une liaison virtuelle pour connecter des sites distants aux locaux centraux de l’écosystème NFV. Cette approche permet de fournir un canal efficace et sécurisé pour prendre en charge la NFV et les communications de données entre les sites d’un écosystème NFV, réduisant ainsi la probabilité que des parties externes accèdent et/ou modifient des informations sensibles concernant les processus d’orchestration NFV et les données des services déployés. Dans ce contexte, le protocole décrit également une méthodologie spécifique pour partager en toute sécurité les informations d’identification VPN avec les sites externes qui permettra l’intégration de nouvelles infrastructures. Le protocole a été illustré à l’aide de l’écosystème NFV mis à disposition à 5TONIC par l’Universidad Carlos III de Madrid, Telefónica et IMDEA Networks Institute, bien qu’il soit générique pour être utilisé dans d’autres environnements NFV répondant aux exigences préalables mentionnées à l’étape 1 de ce protocole.

En outre, il convient de souligner l’utilisation exclusive d’outils et de logiciels open source pour la mise en œuvre du protocole. Malgré les fonctionnalités potentiellement bénéfiques qui pourraient être offertes par différentes solutions propriétaires (par exemple, Fortinet³⁵), l’utilisation de développements open source a facilité l’intégration de tous les éléments englobés par le protocole en raison de leurs caractéristiques inhérentes telles que la rentabilité, un support logiciel étendu fourni par la communauté open source et un haut niveau de fiabilité, pour n’en nommer que quelques-uns. En outre, l’utilisation de technologies open source peut également favoriser des synergies entre des composants de nature similaire. Par exemple, afin de surveiller l’état de la connexion VPN pour les clients utilisant la plate-forme, le service VPN implémenté tout au long du protocole pourrait s’appuyer sur l’outil de surveillance open-vpn³⁶ (un outil de surveillance basé sur Python capable d’interagir avec les serveurs OpenVPN).

D’autre part, la spécification de protocole prend en compte l’instanciation de services de mise en réseau sur différents sites à des fins de validation. À cet égard, il est important de souligner que le déploiement de services sur un site donné est subordonné à la disponibilité de ressources de calcul, de stockage et de réseau sur le site, ainsi que d’équipements spécialisés qui pourraient être nécessaires pour effectuer le déploiement (par exemple, des SAV compatibles NFV). Il ne s’agit pas d’une limitation du protocole et devrait être pris en compte par les parties prenantes intéressées à reproduire l’expérience décrite dans le présent document.

En outre, il convient de noter que le temps nécessaire pour effectuer le déploiement des services réseau dépend fortement de plusieurs facteurs tels que le chemin réseau entre l’orchestrateur et les différents VIM, les performances des communications de données entre le VIM et ses nœuds de calcul gérés, ainsi que la nature intrinsèque de ces nœuds de calcul (non seulement en raison de leurs ressources informatiques disponibles, mais aussi les technologies incorporées pour effectuer la virtualisation des fonctions réseau).

Enfin, et compte tenu des performances exceptionnelles que cette plate-forme et son service VPN ont eu sur les projets européens et les travaux collaboratifs où elle a été utilisée jusqu’à présent (par exemple, 5GINFIRE, 5GRANGE ou 5GCity, mentionnée dans l’introduction de ce document), elle sera considérée comme un élément important dans les projets européens émergents où l’Universidad Carlos III de Madrid, Telefónica et IMDEA Networks Institute y participent, comme le LABYRINTH Horizon 2020, ou des projets nationaux, comme 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/