Déploiement automatisé d'un service de téléphonie de protocole Internet sur les véhicules aériens sans pilote à l'aide de fonctions réseau Virtualisation

Summary

L'objectif du protocole décrit est double : configurer un environnement de virtualisation des fonctions réseau à l'aide de véhicules aériens sans pilote en tant qu'entités de calcul fournissant la structure sous-jacente pour exécuter des fonctions réseau virtualisées et utiliser cet environnement pour soutenir le déploiement automatisé d'un service de téléphonie de protocole Internet fonctionnel sur les véhicules aériens.

Abstract

Le paradigme de la virtualisation des fonctions réseau (NFV) est l'une des technologies clés permettant dans le développement de la^5e génération de réseaux mobiles. Cette technologie vise à réduire la dépendance vis-à-vis du matériel dans la fourniture de fonctions et de services réseau en utilisant des techniques de virtualisation qui permettent la softwarization de ces fonctionnalités sur une couche d'abstraction. Dans ce contexte, on s'intéresse de plus en plus à l'exploration du potentiel des véhicules aériens sans pilote (UAV) pour offrir une plate-forme flexible capable de permettre des opérations RENTABLEs de VN sur des zones géographiques délimitées.

Pour démontrer la faisabilité pratique de l'utilisation des technologies NFV dans les plates-formes de drones, un protocole est présenté pour mettre en place un environnement NFV fonctionnel basé sur les technologies open source, dans lequel un ensemble de petits drones fournissent les ressources de calcul qui prennent en charge déploiement de services réseau modérément complexes. Ensuite, le protocole détaille les différentes étapes nécessaires pour soutenir le déploiement automatisé d'un service de téléphonie par protocole Internet (IP) sur un réseau de drones interconnectés, en tirant parti des capacités de l'environnement NFV configuré. Les résultats de l'expérimentation démontrent le bon fonctionnement du service après son déploiement. Bien que le protocole se concentre sur un type spécifique de service réseau (c.-à-d. la téléphonie IP), les étapes décrites peuvent servir de guide général pour déployer d'autres types de services réseau. D'autre part, la description du protocole prend en compte l'équipement et le logiciel en béton pour configurer l'environnement NFV (par exemple, des ordinateurs à carte unique spécifiques et des logiciels open source). L'utilisation d'autres plates-formes matérielles et logicielles peut être possible, bien que l'aspect de configuration spécifique de l'environnement NFV et du déploiement du service puisse présenter des variations par rapport à celles décrites dans le protocole.

Introduction

L'un des objectifs les plus convoités dans la nouvelle ère des communications mobiles (le plus communément connu sous le nom de 5^e génération mobile ou 5G) est d'être en mesure de fournir des services de technologie de l'information robustes dans les situations où l'infrastructure de télécommunications primaires peut ne pas être disponible (par exemple, en raison d'une urgence). Dans ce contexte, les UAV reçoivent de plus en plus d'attention de la part du milieu de la recherche en raison de leur polyvalence inhérente. Il existe de nombreuses œuvres qui utilisent ces dispositifs comme pierre angulaire pour la fourniture d'une grande variété de services. Par exemple, la littérature a analysé la capacité de ces dispositifs à construire une infrastructure de communication aérienne pour accueillir les services multimédias^1,2,3. En outre, des recherches antérieures ont montré comment la coopération entre plusieurs drones peut étendre la fonctionnalité de différents services de communication tels que la surveillance⁴, la recherche et le sauvetage collaboratifs^5,6,7,8, ou l'agro-industrie⁹.

D'autre part, la technologie NFV a acquis une grande importance au sein des opérateurs de télécommunications comme l'un des principaux facilitateurs 5G. NFV représente un changement paradigmatique en ce qui concerne l'infrastructure de télécommunications en allégeant la dépendance actuelle des appareils réseau sur le matériel spécialisé grâce à la softwarization des fonctionnalités du réseau. Cela permet un déploiement flexible et agile de nouveaux types de services de communication. À cette fin, l'Institut européen des normes de télécommunications (ETSI) a formé un groupe de spécifications pour définir le cadre architectural NFV¹⁰. En outre, l'ETSI accueille actuellement le groupe Open Source Mano (OSM)¹¹, qui est en charge du développement d'une pile logicielle NFV Management and Orchestration (MANO) alignée sur la définition du cadre architectural ETSI NFV.

Compte tenu de toutes les considérations susmentionnées, la convergence synergique entre les drones et les technologies NFV est actuellement à l'étude dans le développement de nouvelles applications et services de réseau. Ceci est illustré par plusieurs travaux de recherche dans la littérature qui soulignent les avantages de ces types de systèmes^14,15,16, identifier les défis de cette convergence et ses aspects manquants, mettre en évidence les futures lignes de recherche sur ce sujet¹⁷, et présenter des solutions pionnières basées sur les technologies open source.

En particulier, l'intégration des technologies NFV dans l'arène des drones permet le déploiement rapide et flexible de services et d'applications réseau sur des zones géographiques délimitées (par exemple, un service de téléphonie IP). Suivant cette approche, un certain nombre de drones peuvent être déployés sur un emplacement spécifique, transportant des plates-formes de calcul sous forme de charge utile (p. ex., ordinateurs à carte unique de petite taille). Ces plates-formes de calcul fourniraient une infrastructure réseau programmable (c.-à-d., une infrastructure NFV) sur la zone de déploiement, soutenant l'instantanéisation des services et applications réseau sous le contrôle d'une plate-forme MANO.

Malgré les avantages, la réalisation de ce point de vue présente un ensemble de défis fondamentaux qui doivent être soigneusement abordés, tels que l'intégration appropriée de ces plates-formes de calcul comme une infrastructure NFV, en utilisant une pile de logiciels NFV existantes, de sorte qu'un service d'orchestration NFV peut déployer des fonctions virtuelles sur les drones; les contraintes en termes de ressources informatiques fournies par les plates-formes de calcul, car les drones qui les transportent peuvent généralement présenter des limites en termes de taille, de poids et de capacité de calcul de l'équipement de charge utile; le bon placement des fonctions virtuelles sur les drones (c.-à-d. la sélection du meilleur candidat UAV pour déployer une fonction virtuelle particulière); le maintien des communications de contrôle avec les uAV afin de gérer le cycle de vie des VNF malgré la disponibilité potentiellement intermittente des communications réseau avec eux (par exemple, causée par des contraintes de mobilité et de batterie); le temps de fonctionnement limité des uAV en raison de leur consommation de batterie; et la migration des fonctions virtuelles lorsqu'un Drone doit être remplacé en raison de son épuisement de la batterie. Ces avantages et défis sont détaillés dans les travaux précédents^18,19 qui comprend la conception d'un système NFV capable de soutenir le déploiement automatisé des fonctions et des services réseau sur les plates-formes de drones, ainsi que la validation de la faisabilité pratique de cette conception.

Dans ce contexte, ce document se concentre sur la description d'un protocole permettant le déploiement automatisé de services réseau modérément complexes sur un réseau de drones utilisant les normes NFV et les technologies open source. Pour illustrer les différentes étapes du protocole, une refonte d'une expérience présentée dans Nogales et al.¹⁹ est présentée, consistant en le déploiement d'un service de téléphonie IP. Pour faciliter la reproductibilité de ce travail, le vol réel est considéré comme facultatif dans la procédure présentée, et les résultats de performance sont obtenus avec les dispositifs uAV au sol. Les lecteurs intéressés devraient être en mesure de reproduire et de valider l'exécution du protocole, même dans un environnement de laboratoire contrôlé.

La figure 1 illustre le service réseau conçu pour cette procédure. Ce service réseau est construit comme une composition d'unités spécifiques de softwarization (classées dans le paradigme NFV comme fonctions de réseau virtuel, ou VNFs) et fournit la fonctionnalité d'un service de téléphonie IP aux utilisateurs à proximité des drones. Le VNF composant le service sont définis comme suit :

• Point d'accès VNF (AP-VNF) : Ce VNF fournit un point d'accès Wi-Fi à l'équipement de l'utilisateur final (c.-à-d. les téléphones IP dans cette expérience).
• Serveur de téléphonie IP VNF (IP-phonphony-server-VNF): Il est responsable de la gestion des messages de signalisation d'appel qui sont échangés entre les téléphones IP pour établir et mettre fin à un appel vocal.
• Système de nom de domaine VNF (DNS-VNF) : Ce VNF fournit un service de résolution de noms, qui est généralement nécessaire dans les services de téléphonie IP.
• Routeur d'accès VNF (AR-VNF) : fournit des fonctionnalités de routage réseau, supportant l'échange de trafic (c.-à-d. la signalisation d'appel dans cette expérience) entre les téléphones IP et le domaine de l'opérateur de télécommunication.
• Le routeur central VNF (CR-VNF) : fournit des fonctionnalités de routage réseau dans le domaine des opérateurs de télécommunications, offrant l'accès à des services spécifiques à l'opérateur (c.-à-d. le serveur de téléphonie IP) et à des réseaux de données externes.

En outre, la figure 1 présente les dispositifs physiques utilisés pour l'expérience, comment ils sont interconnectés, et l'attribution spécifique des VNF aux appareils.

Protocol

1. Requis préalables pour l'expérience

1. Installer la pile logicielle de gestion et d'orchestration (MANO) fournie par le projet Open Source MANO (OSM). Plus précisément, cette expérience utilise OSM Release FOUR²⁰, qui peut être exécuté dans un seul ordinateur serveur ou dans une machine virtuelle (VM) répondant aux exigences spécifiées par la communauté OSM: Ubuntu 16.04 comme système d'exploitation (64 bits image variante), deux unités de traitement central (CCO), 8 Go de mémoire d'accès aléatoire (RAM), un disque de stockage de 40 Go, et une interface réseau unique avec accès Internet. La procédure d'installation de l'OSM Release FOUR ainsi que ses détails techniques sont disponibles dans la documentation en ligne fournie par la communauté OSM²¹.
2. Configurer une plate-forme de cloud computing, fournissant les fonctions d'un gestionnaire d'infrastructure virtuel (VIM) conforme à OSM Release FOUR. Pour cette expérience, OpenStack version Ocata²² est utilisé, en cours d'exécution dans un VM avec Ubuntu 16.04 comme système d'exploitation, quatre processeurs, 16 Go de RAM, et 200 Go disque de stockage. Dans l'expérience, le VIM gère une infrastructure NFV (NFVI) intégrée par deux ordinateurs serveurs de haut niveau, chacun avec Ubuntu 16.04 comme système d'exploitation, huit processeurs, 128 Go de RAM, et 4 tb disque de stockage). Toutes les informations sur la mise en place d'une plate-forme de cloud computing sont incluses dans le guide d'installation inclus dans la documentation OpenStack²³. Cette plate-forme cloud est appelée plate-forme cloud centrale.
3. Mettre en place une plate-forme cloud computing supplémentaire pour les drones est appelé la plate-forme cloud UAV.
   1. Assurez-vous que cette plate-forme dispose d'un VIM basé sur OpenStack version Ocata. Dans ce cas, les ressources utilisées par l'installation VIM sont Ubuntu 16.04 comme système d'exploitation, deux processeurs, 6 Go de RAM, 100 Go de disque de stockage, et un adaptateur USB Wi-Fi externe.
   2. Le NFVI intégré dans cette plate-forme cloud se compose d'un seul serveur de calcul fixe (Ubuntu 16.04 comme système d'exploitation, huit processeurs, 8 Go de RAM, 128 Go de disque de stockage, et un adaptateur USB Wi-Fi externe) et trois ordinateurs à carte unique (SBC). Ces derniers fournissent une plate-forme matérielle qui peut facilement être embarquée sur un drone. Voir la section 3 pour la procédure de configuration d'une plate-forme cloud UAV avec ces appareils comme nœuds de calcul.
4. Équipez chaque SBC d'un matériel d'alimentation de batterie fixé sur le dessus (HAT) pour assurer le fonctionnement de ces unités même lorsqu'elles sont en mouvement, transportées par un drone.
   REMARQUE: L'étape 1.5 est facultative parce que la fourniture du service réseau dans l'expérience ne dépend pas d'avoir des drones. En outre, les SBC sont transportés comme la charge utile des Drones et aucune autre connexion supplémentaire (par exemple, Ethernet ou USB) sont nécessaires, parce que les communications réseau nécessaires pour le bon fonctionnement du service de téléphonie IP sont fournis par les SBC, par le biais de leurs adaptateurs Wi-Fi, et l'alimentation est fournie par la HAT d'alimentation mentionnée à l'étape 1.4.
5. Fixez chaque SBC comme charge utile d'un drone à l'intermédiaire d'un accessoire de fixation. Dans cette expérience, trois drones commerciaux ont été choisis pour transporter les unités de calcul offertes par les SBC.
6. Sélectionnez deux téléphones sans fil voix-sur-IP (VoIP) qui prennent en charge la norme de communications sans fil IEEE 802.11b; ce modèle fournit des communications sans fil via Wi-Fi. Comme alternative, l'appel vocal pourrait être exécuté en utilisant des applications softphone telles que Linphone²⁴ ou Jitsi²⁵.
7. En tant qu'exigence expérimentale, assurez-vous de la disponibilité de : a) des communications de couche-3 entre la pile logicielle OSM et chacune des VM pour permettre le déploiement orchestré du service réseau développé pour cette expérience, b) les communications de couche-3 entre l'OSM et les VNF à chaque plate-forme cloud pour prendre en charge les procédures de configuration VNF, et c) les communications couche-3 entre les VNF fonctionnant à chaque VIM pour permettre le bon fonctionnement du service réseau.
8. Tout le contenu nécessaire à la production de l'expérience est fourni dans le référentiel d'expérience publique http://vm-images.netcom.it.uc3m.es/JoVE/.

2. Validation de la fonctionnalité des unités de softwarization par émulation

REMARQUE : Pour prouver le bon fonctionnement du service réseau de l'expérience (voir Figure 1) dans des conditions de déploiement réalistes, une plate-forme d'émulation spécifique basée sur les conteneurs Linux²⁶ et ns-3²⁷ a été utilisée. Cette plate-forme permet d'imiter les liaisons aériennes multi-saut et de définir les caractéristiques de ces liens (p. ex., la longueur des liaisons de communication sans fil, le modèle des pertes de paquets de données, la technologie radio utilisée dans les communications sans fil, etc.). Ainsi, cette section du protocole décrit les étapes à suivre pour vérifier le bon fonctionnement du service de téléphonie IP dans des conditions réalistes de liaison de communication sans fil à travers la plate-forme d'émulation.

1. Téléchargez la plate-forme d'émulation à partir du référentiel d'expérience. La plate-forme est disponible sous forme de machine virtuelle, nommée "uav-nfv-jove-experiment.qcow", conforme à la technologie de virtualisation KVM²⁸. Cette machine contient un modèle précréé qui émule le service réseau et le scénario multi-UAV présenté dans la figure 1 et un utilisateur avec des privilèges d'administrateur capables d'exécuter ce modèle.
   REMARQUE : Par défaut, les étapes suivantes sont automatiquement exécutées lorsque la machine virtuelle de la plate-forme d'émulation est lancée : a) l'environnement virtuel est configuré pour activer l'émulation du réseau (c.-à-d. interfaces réseau, ponts Linux^29); b) les conteneurs Linux représentant les différents composants physiques du banc d'essai (c.-à-d. les SBC et le serveur de calcul fixe pour la plate-forme cloud UAV, et le serveur de calcul pour la plate-forme cloud centrale) sont créés; c) les fonctions fournies par les différents VNF du service de téléphonie IP (c.-à-d. points d'accès, routeurs, dNS et serveur de téléphonie IP) sont déployées sous forme de conteneurs Linux sur leurs SBC émulés correspondants et leurs serveurs de calcul.
2. Avant le processus de validation, configurez un réseau aérien multi-hop émulé à l'aide du simulateur ns-3, afin de permettre la connectivité entre les différents participants au réseau. Cette procédure imitera les communications sans fil réalistes qui ont lieu dans le scénario décrit à la figure 1 (c.-à-d. le réseau ad-hoc Wi-Fi, qui permet l'échange de données entre les nœuds de la plate-forme cloud UAV et les réseaux sans fil offerts par les deux points d'accès Wi-Fi fournis dans le service).
   1. Créez le réseau aérien multi-hop. À cette fin, exécutez le script multi-hop-aerial-net.sh (disponible dans la machine de plate-forme d'émulation) en utilisant la commande suivante : sudo sh/home/jovevm/scripts/multi-hop-aerial-net.sh 'gt; multi-hop-aerial-net-trace.log 2 'gt'amp;1 et 1 '. Cette commande représente la trace de simulation dans le fichier de journal spécifié pour permettre le débogage en cas d'erreurs.
   2. Vérifiez si le réseau a été créé avec succès. À cette fin, vérifiez si les conteneurs Linux "IP-phone-a" et "IP-phone-b" (illustrés dans la figure 1 comme l'équipement de l'utilisateur final qui se connecte à un AP-VNF) ont obtenu une adresse IP via le service DHCP, qui n'est accessible que par le réseau aérien multi-hop. L'état du conteneur Linux exécuté dans la machine d'émulation, ainsi que leurs adresses IP, peuvent être vérifiés à l'aide de la liste de commande lxc.
3. Vérifier la capacité du service réseau imité pour traiter les messages de signalisation nécessaires à la configuration de l'appel de téléphonie IP. À cette fin, les conteneurs Linux "IP-phone-a" et "IP-phone-b" ont installé l'outil "SIPp"³⁰. "SIPp" fournit la fonctionnalité pour émuler un téléphone IP créant les messages de signalisation mentionnés, les envoyer à un serveur de téléphonie IP, et traiter la réponse pour vérifier le bon fonctionnement de ce dernier.
   1. Exécutez le script test-signaling.sh dans les deux conteneurs, qui exécute l'outil "SIPp" pour générer et envoyer des messages de signalisation à l'IP-téléphonie-serveur-VNF.
   2. Vérifiez l'écran de scénario fourni par l'exécution de l'étape précédente. La réception de la réponse "200" montre le bon fonctionnement de l'IP-téléphonie-serveur-VNF.
4. Validez le fait que le service réseau peut traiter le trafic de données généré lors d'un appel téléphonique IP. Pour ce faire, l'outil de planification des flux "Trafic"³¹ est installé dans les conteneurs Linux "IP-phone-a" et "IP-phone-b".
   1. Exécutez la commande suivante pour démarrer l'agent serveur de Trafic: lxc exec IP-phone-b sh called-party.sh.
   2. Ensuite, exécutez la commande suivante pour démarrer l'agent client de Trafic et obtenir les statistiques du réseau: lxc exec IP-phone-a sh caller.sh. Le trafic de données imitant un appel vocal est terminé après 60 s. Le script affiche un message de confirmation et les mesures de performances les plus significatives concernant le trafic vocal.
   3. Vérifiez les mesures obtenues et vérifiez que le service de téléphonie IP peut effectivement prendre en charge une conversation vocale interactive. Pour ce faire, voir l'information incluse dans la section sur les résultats représentatifs.

3. Construction de plate-forme cloud UAV

1. Sélectionnez le modèle de SBC qui peut fournir le substrat de virtualisation pour exécuter des VNF légers. Les spécifications techniques des appareils SBC utilisés au cours de l'expérience sont : quatre processeurs, 1 Go de RAM et un disque de stockage de 32 Go. En outre, chaque SBC dispose de trois interfaces réseau : une interface Ethernet, une interface Wi-Fi intégrée et un adaptateur USB Wi-Fi externe.
2. Préparer les SBC à être ensuite intégrés dans la plate-forme cloud UAV.
   1. Installez Ubuntu Mate³² 16.04.6 comme système d'exploitation, étant donné que les paquets d'installation OpenStack sont inclus dans cette distribution Linux.
   2. Installez et configurez les paquets requis comme indiqué dans la documentation OpenStack³³ pour permettre aux SBC d'agir comme nœuds de calcul de la plate-forme cloud UAV. Suivant le guide précédent, activez l'utilisation des conteneurs Linux dans la configuration des paquets OpenStack. La virtualisation des conteneurs est utilisée en raison des contraintes de ressources des appareils qui peuvent généralement être embarqués sur des drones de petite taille.
   3. Dans le SBC, téléchargez et exécutez le script rpi-networking-configuration.sh, disponible dans le référentiel d'expérience. Ce script permet les communications sans fil des SBC, ainsi que la configuration requise pour permettre la création de réseaux virtuels attachés aux interfaces sans fil.
   4. Téléchargez et exécutez le script VIM-networking-configuration.sh, disponible dans le référentiel d'expérience, dans l'hôte exécutant la plate-forme cloud UAV VIM. Ce script supervise la mise en place des communications sans fil du VIM pour permettre l'échange d'informations avec les SBC.
      REMARQUE : Une fois que le réseau est bien configuré et que le VIM dispose d'une connectivité avec les SBC, le VIM les intègre automatiquement dans la plate-forme cloud UAV en tant qu'unités de calcul capables d'exécuter des VNF
3. Créez une zone de disponibilité OpenStack pour chacun des SBC. Cela permettra de déployer chacune des VNF légères de l'expérience dans une unité de drone appropriée. Pour ce faire, connectez-vous à l'interface utilisateur graphique Web fournie par le VIM avec les informations d'identification de l'administrateur, créez les zones de disponibilité dans l'onglet Administrateur et Système et Agrégats d'hôte, et modifiez chaque zone de disponibilité pour ajouter l'hôte approprié (c.-à-d., chaque SBC intégré dans la plate-forme cloud UAV).
4. Vérifier la configuration correcte de la plate-forme cloud UAV. Pour ce faire, accédez à l'onglet D'information système de l'Administrateur et du Système avec la même connexion que dans l'étape précédente, et cliquez dans la section Service informatique et agents réseau pour vérifier que l'état des éléments affichés est « Vivant » et « UP ».

4. Configuration de l'expérience

1. Téléchargez les images VNF qui implémenter les différents composants du service de téléphonie IP : l'AP-VNF, le DNS-VNF, IP-phonphony-server-VNF, l'AR-VNF et le CR-VNF. Ces images peuvent être téléchargées à partir du référentiel d'expérience.
2. Téléchargez les images VNF à leur correspondant VIM (c'est-à-dire l'AP-VNF et le DNS-VNF sur la plate-forme cloud UAV VIM) et la VoIP-VNF sur la plate-forme cloud VIM. Pour ce faire, connectez-vous à l'interface utilisateur graphique web fournie par chaque VIM avec les informations d'identification de l'administrateur, cliquez sur le bouton Créer l'image de l'administrateur 'gt; Système 'gt; onglet Images, et créer une image en utilisant le formulaire affiché et en sélectionnant l'image appropriée. Ce processus est effectué au VIM correspondant pour chaque image qui a été téléchargée dans l'étape précédente.
3. Téléchargez les descripteurs VNF (VNFD) de l'expérience à partir du référentiel d'expérience. Ces descripteurs fournissent les modèles qui décrivent les besoins opérationnels d'un VNF, ainsi que les stratégies de placement qui indiquent la zone de disponibilité en charge de l'hébergement du VNF lui-même. Plus d'informations sur les descripteurs NFV peuvent être trouvées dans le modèle d'information de l'OSM³⁴.
4. Téléchargez les VNFD. Utilisez un navigateur Web pour accéder à l'interface utilisateur graphique OSM et connectez-vous avec les informations d'identification de l'administrateur. Ensuite, faites glisser et déposez les VNFD dans l'onglet Paquets VNF.
5. Téléchargez le descripteur de services réseau (NSD) à partir du référentiel d'expérience. Ce descripteur est un modèle qui spécifie les VNF comprenant le service, ainsi que la façon dont ces VNF sont interconnectés.
6. Téléchargez le NSD. Faites glisser et déposez le NSD dans l'onglet NS Packages de l'interface utilisateur graphique OSM.
7. À l'aide de l'interface utilisateur graphique d'OSM, ajoutez un compte VIM pour la plate-forme cloud UAV VIM et pour la plate-forme cloud de base VIM. Pour ce faire, accédez à l'onglet comptes VIM avec les informations d'identification de l'administrateur, cliquez sur le bouton ' Nouveau VIM et remplissez le formulaire affiché avec les informations demandées. Répétez cette action pour les deux VIP.

5. Exécution de l'expérience

1. Déployer le service réseau. À partir de l'onglet paquets NS de l'interface utilisateur graphique OSM, cliquez sur le bouton Instantiate NS du NSD téléchargé à l'étape 4.6. Ensuite, remplissez le formulaire affiché, indiquant le VIM qui sera utilisé pour déployer chaque VNF composant le NS. De plus, l'OSM est responsable du traitement des politiques de placement indiquées dans les VNFD afin de spécifier la zone de disponibilité VIM dont la zone de disponibilité (c.-à-d. une unité de calcul dans notre banc d'essai) est chargée d'héberger chaque VNF. Pour cette expérience, les VNF sont placés dans les unités de calcul comme illustré dans la figure 1.
   REMARQUE : En tant que méthode alternative, l'OSM fournit une interface de ligne de commande qui permet l'interaction directe de l'utilisateur. Un utilisateur reproduisant cette expérience peut utiliser cette interface de ligne de commande, au lieu de l'interface graphique, pour exécuter les différentes étapes définies dans ce protocole, en particulier les étapes liées à l'intégration d'un VNF ou un descripteur NS, ainsi que le déploiement d'un service réseau.
2. Attendez que l'interface utilisateur graphique OSM indique le succès sur le déploiement du service réseau.
   REMARQUE : Le fonctionnement du service réseau est totalement indépendant du vol des drones : le service de téléphonie IP peut être fourni lorsque les drones volent ou économisent la consommation de batterie perchée sur une surface. Ainsi, l'étape 5.3 est facultative.
3. Enlève les drones. Connectez-vous à l'application mobile et contrôlez le vol de chaque UAV pour le maintenir de façon stable à une hauteur intermédiaire et éviter la turbulence causée par la rotation des moteurs près d'une surface.
4. Préparer chacun des téléphones IP pour effectuer l'appel.
   1. Connectez un téléphone VoIP sans fil à chacun des points d'accès offerts par le service réseau. À cette fin, spécifiez le SSID (Identification de l'ensemble deservice ) dans le menu 'gt; onglet sans fil 'sSID et choisissez le mode infrastructure dans le menu 'gt; sans fil 'gt; section mode réseau. Enfin, sélectionnez la configuration de réseau via le protocole de configuration de l'hôte dynamique (DHCP) dans le menu 'gt; Paramètres nets 'gt; onglet mode réseau.
   2. Configurer les paramètres du protocole d'initiation de session (SIP) pour permettre l'échange approprié de messages de signalisation avec le serveur de téléphonie IP. Dans ce contexte, l'accès à l'onglet Paramètres menu et SIP et spécifier le nom de l'hôte du serveur de téléphonie IP VNF ("dronesVoIP.net") dans le registraire et le serveur de procuration IP .gt; Proxy IP tablatures. En outre, créez un compte d'utilisateur introduisant le nom de l'utilisateur (par exemple, caller-A) dans le compte d'utilisateur et le numéro de téléphone et le compte d'utilisateur .gt; sections nom d'utilisateur.
   3. Créez une entrée dans l'annuaire téléphonique de l'un des téléphones IP fournissant les informations de l'utilisateur qui doit être appelé. Pour ce faire, sélectionnez le Menu 'gt; Phonebook 'gt; Ajouter l'onglet Entrée, et remplir les paramètres demandés qui apparaissent dans l'affichage comme suit: Afficher le nom de l'appelant-B; Informations sur l'utilisateur - caller-B; Ip hôte et dronesVoIP.net; Port 5060. Enfin, sélectionnez l'option "Proxy" par rapport au P2P (peer-to-peer).
5. Commencez l'appel à l'autre partie. Pour ce faire, sélectionnez la partie appelée en utilisant le menu 'gt; Phonebook 'gt; Option de recherche du téléphone IP. Ensuite, appuyez sur le bouton d'appel. Une fois que l'autre téléphone IP commence à sonner, acceptez l'appel entrant avec le bouton d'appel.

6. Procédure de collecte des résultats expérimentaux

1. Connectez un ordinateur portable de base à l'un des AP sans fil et exécutez l'outil de la ligne de commande ping à l'adresse IP du téléphone connecté à l'autre AP pendant 180 s. L'adresse IP peut être vérifiée dans le Menu 'gt; Information 'gt; option d'adresse IP du téléphone IP une fois que la connexion est établie avec l'AP. Enregistrer les mesures Aller-Retour (RTT), rediriger la sortie fournie par l'outil de ping dans un fichier.
2. Exécutez l'outil de ligne de commande tcpdump dans l'un des VNF AP en cours d'exécution pour capturer le trafic échangé lors de l'appel IP. Enregistrez ce trafic dans un fichier permettant l'indicateur d'écriture de l'outil de ligne de commande au moment de l'exécution et spécifiant le nom du fichier.
3. Effectuez un nouvel appel téléphonique IP. Maintenir l'appel pour la période de temps désirée (p. ex., 1 min). Ensuite, terminez l'appel, en appuyant sur le bouton raccrocher de l'un des téléphones IP.
4. Conservez les fichiers générés par les outils tcpdump et ping pour un traitement ultérieur. Voir Résultats représentatifs.

Representative Results

Sur la base des données obtenues lors de l'exécution de l'expérience, dans lesquelles un véritable appel VoIP est exécuté et suivant les étapes indiquées par le protocole pour recueillir ces informations, la figure 2 illustre la fonction de distribution cumulative du délai de bout en bout mesuré entre deux éléments d'équipement de l'utilisateur final (c.-à-d. un ordinateur portable de marchandises et un téléphone IP). Cet équipement utilisateur représente deux appareils qui sont interconnectés par le biais des VNF AP du service réseau déployé. Plus de 80 % des mesures de retard de bout en bout étaient inférieures à 60 ms, et aucune d'entre elles n'était supérieure à 150 ms, ce qui garantit des mesures de retard appropriées pour l'exécution d'un appel vocal.

La figure 3 illustre l'échange de messages de signalisation DNS et SIP. Ces messages correspondent à l'enregistrement d'un des utilisateurs dans le serveur de téléphonie IP (c'est-à-dire à l'utilisateur dont le téléphone IP est connecté à l'AP VNF où s'exécute l'outil "tcpdump") et à la mise en place de l'appel vocal.

Enfin, la figure 4 et la figure 5 montrent le trafic de données capturé pendant l'appel. En particulier, le premier représente le flux constant de paquets vocaux transmis et reçus par l'un des téléphones sans fil pendant l'appel, tandis que le second illustre la nervosité dans la direction avant avec une valeur moyenne inférieure à 1 ms.

Les résultats obtenus dans l'expérience pour les chiffres de retard (retard de bout en bout et de la nervosité) répondent aux recommandations spécifiées par l'Union internationale des télécommunications - Secteur de normalisation des télécommunications (UIT-T)³⁵. En conséquence, l'appel vocal a progressé sans pépins et une bonne qualité sonore. Cette expérience a validé la faisabilité pratique de l'utilisation des technologies NFV et des drones pour déployer un service de téléphonie IP fonctionnel.

Figure 1 : Aperçu du service réseau, illustrant les VNF, les entités dans lesquelles ils sont exécutés et les réseaux virtuels nécessaires à la fourniture du service de téléphonie IP. Veuillez cliquer ici pour voir une version plus grande de ce chiffre.

Figure 2 : Retard de bout en bout. Représentation du délai de bout en bout offert à l'équipement de l'utilisateur final relié aux VFN AP. À cette fin, la fonction de distribution cumulative du délai de bout en bout a été calculée à partir des échantillons de RTT mesurés obtenus avec l'outil de la ligne de commande «ping». Veuillez cliquer ici pour voir une version plus grande de ce chiffre.

Figure 3 : Enregistrement des utilisateurs et messages de signalisation d'appels. Illustration du trafic de signalisation (DNS et SIP) échangé pour enregistrer un utilisateur dans le serveur de téléphonie IP et pour créer et mettre fin à la session multimédia qui prend en charge l'exécution de l'appel vocal. Veuillez cliquer ici pour voir une version plus grande de ce chiffre.

Figure 4 : Flux de paquets vocaux. Représentation du trafic vocal échangé pendant l'appel, mesurée à l'un des VNF AP. (Abbreviations: RX - recevoir, RX - transmettre, RTP - protocole de transport en temps réel). Veuillez cliquer ici pour voir une version plus grande de ce chiffre.

Figure 5 : Évolution de la nervosité du réseau pendant l'appel. Représentation de la nervosité vécue par les paquets de voix transmis dans la direction avant d'un téléphone à l'autre. Veuillez cliquer ici pour voir une version plus grande de ce chiffre.

Discussion

L'un des aspects les plus importants de cette expérience est l'utilisation de technologies de virtualisation et de normes NFV avec les plates-formes UAV. NFV présente un nouveau paradigme visant à découpler la dépendance matérielle des fonctionnalités du réseau, permettant ainsi la fourniture de ces fonctionnalités grâce à la softwarization. Par conséquent, l'expérience ne dépend pas de l'utilisation de l'équipement matériel spécifié dans le protocole. Alternativement, différents modèles d'ordinateurs à carte unique peuvent être sélectionnés, tant qu'ils sont en ligne avec les dimensions et la capacité de transport des drones et qu'ils prennent en charge les conteneurs Linux.

Malgré cette flexibilité en termes de sélection matérielle, tout le contenu fourni pour la reproductibilité de l'expérience est orienté vers l'utilisation de technologies open source. Dans ce contexte, les aspects de configuration et les outils logiciels sont conditionnés à l'utilisation de Linux comme système d'exploitation.

D'autre part, l'expérience considère l'interopération de deux plates-formes de calcul différentes (c'est-à-dire la plate-forme cloud UAV et la plate-forme cloud centrale) pour fournir un service réseau modérément complexe. Cependant, ce n'est pas strictement nécessaire, et le protocole pourrait être suivi pour prendre en charge les scénarios dans lesquels seule la plate-forme cloud UAV est impliquée.

En outre, la solution présentée pourrait potentiellement être utilisée dans d'autres environnements, où des plates-formes matérielles limitées en ressources pourraient être disponibles avec la capacité nécessaire pour exécuter des conteneurs de virtualisation (par exemple, l'Internet des objets, ou IoT, environnements). Dans tous les cas, l'applicabilité de cette solution à différents environnements et ses adaptations potentielles nécessiteront une étude approfondie au cas par cas.

Enfin, il convient de noter que les résultats présentés ont été obtenus en laboratoire et avec les dispositifs uAV cloués au sol ou suivant un plan de vol limité et bien défini. D'autres scénarios impliquant des déploiements en plein air peuvent introduire des conditions affectant la stabilité du vol des drones, et donc la performance du service de téléphonie IP.

Materials

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