Télécharger le fichier original (Mémoire de fin d’études)

Architecture de communication pour une flotte de drones

L’architecture de communication d’une flotte de drones définit les règles d’échanges entre les différentes entités (consitutées par les drones et la station sol) dans le réseau. Différents types d’architecture peuvent être envisagés en fonction des caractéristiques des nœuds et du cahier des charges de la mis-sion. Parmi ces différentes architectures, l’architecture ad hoc sans fil sera mise en avant, car elle assure flexibilité et robustesse aux communications entre les drones. Un réseau ad hoc sans fil est caractérisé par une architec-ture qui s’adapte au nombre des nœuds, à leur position géographique et à leur mobilité. Il permet aux différents nœuds de coopérer sans l’utilisation d’une infrastructure réseau fixe préexistante et/ou centralisée. Appliqué aux flottes de drones, ce réseau s’intitule UAANET pour Uav Ad hoc NETwork. Il partage des caractéristiques similaires aux réseaux Mobile Ad hoc Network (MANET), mais présente aussi des particularités en matière de degré de connectivité et de mobilité. Ces caractéristiques sont à prendre en compte dans la définition et la conception d’un protocole de communication dans un réseau UAANET.

Systèmes aéronautiques coopératifs sans pilote

Cette section est consacrée aux systèmes aéronautiques sans pilote constituant le réseau de communication.

Description fonctionnelle d’un drone

Un drone désigne un aéronef sans pilote à bord, muni d’un autopilote 3 embarqué et pou-vant être télécommandé à distance depuis une station sol. Dans la littérature, deux termes sont habituellement employés : UAV et Remotely Piloted Aircraft System (RPAS). A la différence de l’UAV, le RPAS requiert la présence d’un télépilote actif au sol mais pas obligatoirement d’un autopilote à bord. Le terme UAV, quant à lui, désigne un drone possédant à bord un autopilote actif qui le pilote.
Les drones peuvent remplir diverses missions, historiquement dans le cadre d’applications militaires (surveillance d’une cible, renseignement, etc.), mais aussi, récemment, dans le cadre d’applications civiles (audiovisuel, industrie, agriculture). Dans ce manuscrit, nous nous intéressons exclusivement aux drones du domaine civil.
Un drone civil dispose de divers capteurs et embarque une charge utile. Ces éléments par-ticipent à son autonomie et lui permettent d’exécuter diverses applications. Par exemple, dans le domaine de l’audiovisuel, la réalisation d’un reportage a été pendant longtemps executée par des avions ou des hélicoptères pilotés. Non seulement ces missions peuvent être dangereuses et inadaptées aux pilotes, mais peuvent aussi engendrer des coûts consé-quents. Les drones civils réalisent actuellement ces tâches en s’adaptant aux différents types et conditions de missions.
Il existe deux types de drones civils, ce sont les voilures fixes et les multirotors (illustrés par les figures 1.1 et 1.2).
— Les multirotors peuvent être des quadricoptères, hexacoptères, octocoptères ou dé-cacoptères. Ce type de drones est souvent utilisé pour des vols stationnaires ou à très faible vitesse, ce qui les rend particulièrement adaptés à la prise de vue aérienne, photo ou vidéo ;
— les drones à voilure fixe, quant à eux, permettent de couvrir de longues distances ou d’atteindre de hautes altitudes, ils sont plutôt dédiés aux applications topogra-phiques sur de grandes surfaces ou de grands linéaires.
Figure 1.1 : Exemple de drone à voilure fixe Figure 1.2 : Exemple de drone multirotor
Les drones reçoivent les données de contrôle et de commande (qu’on appelle trafic C2 (Contrôle et Commande)) depuis la station sol à une fréquence déterminée. Ils renvoient aussi vers la station sol les informations de configuration concernant les conditions de vol (position, vitesse, etc.) et les données acquises par la charge utile. Ces données permettent à l’opérateur au sol de surveiller le vol et d’intervenir potentiellement sur le drone en lui envoyant des commandes.

Unmanned Aircraft/Aerial Systems

Le Unmanned Aircraft/Aerial System (UAS) est un terme avancé par l’administration fédérale de l’aviation américaine, « Federal Aviation Admnistration » (FAA), pour re-grouper les différentes dénominations indiquées dans le tableau 1.1, l’objectif étant de les unifier afin d’utiliser le principe de système soit utilisé. Dans ce cas, le UAS est composé de drones, de différentes liaisons de communication et de transfert de données, d’une ou plusieurs stations sol et de systèmes additionnels sécurisant la mission. Ces derniers sont ajoutés pour fiabiliser la mission et répondre aux réglementations et aux exigences de certification. Il est à noter que la FAA ainsi que l’agence européenne de la sécurité aé-rienne (EASA), à travers la Direction Générale de l’Aviation Civile (DGAC), préconisent le contrôle permanent du système UAS par un système au sol [DVP08], restriction imposée pour le déploiement d’une flotte de drones et qui sera évoquée dans le chapitre 5. Afin d’en tenir compte, il a été nécessaire d’utiliser une station sol dédiée pour piloter chaque drone de la flotte.

Charge utile

La charge utile d’un drone est l’ensemble des systèmes embarqués qui lui permettent de réaliser sa mission, par exemple, un appareil photo, une caméra vidéo, une caméra multi spéctrale, une caméra thermique, des sondes ou tout autre type de capteurs (mésurant, entre autres, des paramètres dans l’air, tels que la température, la pression ou encore le niveau de pollution). Grâce à sa charge utile, un système de drones peut être utilisé pour inspecter une zone donnée, la cartographie d’une zone déterminée, des relevés thermiques sur des bâtiments d’usine, etc.

Station sol

La station sol (illustrée par la figure 1.3) est un ensemble d’entités physiques et de logiciel qui permettent de contrôler le mouvement des drones. Selon le type de station utilisé, elle peut être munie d’une interface homme-machine qui permet à l’opérateur au sol de surveiller en temps réel la position d’un drone à l’aide d’une carte topographique sur laquelle l’itinéraire du drone est superposé. Il peut également configurer l’altitude et les paramètres de la charge utile.
Grâce à une liaison en temps réel entre la station sol et le drone, le logiciel de supervision (appelé souvent logiciel Ground Control Station (GCS)) permet de visualiser la vidéo capturée par le drone ou encore les photos prises. Toutes les données traitées par ce logiciel sont géoréférencées et peuvent être ainsi enregistrées ou partagées avec d’autres systèmes d’informations géographiques. La station sol dispose également d’équipements de télécommunication en radiofréquence, qui représentent la partie physique caractérisée par l’émetteur, et le récepteur et leurs antennes associées.
Il est important de souligner que la station communique avec les drones à travers des liaisons de commande et contrôle sur un lien de communication montant depuis le sol vers les drones. Dans l’autre sens, la station sol récupère un panel d’informations télémétriques et vidéos sur un lien de communication descendant.

Drones dans des opérations civiles

Généralement, les applications civiles des drones peuvent être divisées en trois catégories : l’audiovisuel, l’industrie et l’agriculture.
• Domaine de l’audiovisuel : il regroupe la plupart des professionnels de l’industrie du
drone. Les utilisations sont les suivantes : la photographie aérienne, la cinématogra-phie, la réalisation de reportages sur une zone difficile d’accès.
• Domaine de l’industrie : certains scénarios d’applications ont été réalisés, tels que :
— la télésurveillance de pipelines pétroliers [HZSS05] ;
— la télésurveillance des voies ferroviaires [MB15] ;
— la cartographie, la topographie ;
— l’inspection détaillée (sites industriels, bâtiments, ouvrages d’art).
• Agriculture : dans le domaine de l’expérimentation agricole, les drones ont un po-tentiel de développement important, car ils permettent de récupérer de manière économique des données essentielles à l’échelle des microparcelles. En effet, cette échelle rend possible l’extraction des pixels de photo pour en permettre une analyse précise et recueillir ainsi l’information de l’image brute issue d’un appareil photo.
Un exemple d’utilisation de drones pour une mission de surveillance est illustré par la figure 1.4.

Flotte de drones

Nous avons évoqué depuis le début du chapitre le fonctionnement d’un système de mini-drones et les différents types d’applications civiles réalisables. Il a été évoqué que l’uti-lisation de ces mini-drones apportait une plus-value qui se manifeste en termes de per-formances et de productivité. Néanmoins, l’aptitude d’un système muni d’un seul drone est limitée dans l’espace et dans le temps [ BS T13]. Donc, pour une mission de plusieurs heures et qui nécessite de parcourir une zone large, l’utilisation d’un seul drone peut être limitée en matière d’autonomie de batterie et de portée (notamment en cas de présence d’obstacles). La collaboration de plusieurs drones est une solution qui offre plusieurs avan-tages :
— Coût : le coût d’acquisition et de maintenance des mini-drones mis en jeu dans une flotte de drones peut être moindre que l’utilisation d’un seul drone de grande taille.
— Mise à l’échelle : l’usage d’un seul drone ne permet de couvrir qu’une zone limitée. En effet, l’étendue de la mission dépend de la batterie et de la présence d’obstacles (par exemple, une montagne). Avec une flotte de drones, il est possible de créer un relais de drones pour contourner les éventuels obstacles et agrandir la zone de couverture de l’opération. Cette fonction sera développée dans ce chapitre, avec le concept du réseau ad hoc de drones, à l’origine d’un réseau de communication autonome.
— Survie de la mission : la mission peut être interrompue en cas de panne d’un élément physique ou logiciel du système UAS. Toutefois, avec une flotte de drones, l’opération peut se poursuivre en cas de panne d’un des drones ou en cas d’épuisement de la batterie en reconfigurant les ressources de la flotte.
— Latence : il a été montré dans [YCBE10] que la densité de nœuds est proportionnelle au temps d’exécution de la mission. Plus le nombre de nœuds dans le réseau est élévé, plus le temps d’exécution de la mission est optimisé.

Architectures de communication possibles pour une flotte de drones

Architecture de communication centralisée

Une architecture de communication centralisée de flotte de drones [FB09] est caractérisée par un lien sans fil direct entre un nœud centralisé (par exemple, la station sol) et les drones aux alentours. Dans cette architecture, chaque drone est directement connecté à la station sol pour transmettre les données de la charge utile et pour recevoir le flux de commande et de contrôle. Les drones ne sont pas directement connectés entre eux, ce qui nécessite d’envoyer les informations entre drones voisins en passant par la station sol. Dans ce cas, la station sol agit comme un nœud relais. Une illustration de cette architecture est montrée par la figure 1.5.a.
Cette architecture comporte plusieurs inconvénients :
— La taille de la bande passante et le débit dépendra du nombre de drones dans le réseau, puisque la station sol communique avec chacun des drones. En conséquence, pour supporter une forte densité du réseau, il convient de fournir une quantité suf-fisante de bande passante qui peut être importante ;
— La latence de transfert d’un paquet de données entre deux drones voisins peut être longue en raison du relais obligé par la station sol [LZL13] ;
— En cas de présence d’un obstacle entre un drone et la station sol (montagne ou bâtiment, par exemple), le signal peut être bloqué et empêcher ainsi les trafics C2 d’être exécutés par les drones. En conséquence, les nœuds ne peuvent s’éloigner que d’une distance maximale de la station sol, limitant ainsi la distance d’opération des drones. Des équipements radio avancés peuvent aussi être déployés, permettant ainsi d’étendre la portée de communication, mais ce genre de système peut générer une forte puissance de transmission [CHKV06], ce qui est interdit d’un point de vue légal [FW12].
— La présence d’une entité centrale dans le réseau le rend également vulnérable, car, si la station sol est hors service suite à une attaque, la disponibilité des drones n’est plus garantie.

Architecture de communication par satellite

Un autre type d’architecture de communication centralisée, envisageable pour établir une communication entre les différents drones, est le déploiement d’un satellite de communica-tion. Dans cette configuration, le satellite fonctionne comme un relais de communication [FB09]. Ses antennes de réception reçoivent les signaux émis depuis la station sol ; ces signaux sont par la suite transposés en fréquence et amplifiés avant d’être retransmis vers les drones. Il existe deux types de satellites utilisables : le satellite géostationnaire et le satellite orbital. Le satellite géostationnaire est situé dans le plan équatorial. Il tourne à la même vitesse et dans le même sens que la terre ; sa trajectoire est ainsi fixe au-dessus d’un point au sol. Le second est un satellite qui couvre des zones géographiques différentes.
L’utilisation des satellites présente l’avantage d’assurer une couverture plus efficace que celle d’une communication centralisée. Cela permet une amélioration d’interconnexion du réseau de communication des drones, indépendamment de leurs trajectoires. Toutefois, cette connectivité nécessite toujours un routage vers un système centralisé qui est, ici, le satellite. Compte tenu du caractère temps réel des trafics applicatifs échangés dans le cas d’une flotte de drones, se produisent des latences non négligeables d’échanges entre les nœuds. De plus, en présence d’obstacles autour de la station sol (un immeuble, par exemple), la communication vers le satellite peut être partiellement atténuée ou complè-tement bloquée.
Une illustration de cette architecture est visible sur la figure 1.5.c.

Architecture de communication réseau cellulaire (Réseau semi-centralisé)

C’est l’architecture utilisée dans le domaine de la téléphonie et qui se fonde sur l’utilisation d’une infrastructure de stations de base. Des cellules sont déployées de façon plus ou moins importante en fonction de la densité du réseau recherchée. Dans chaque cellule, peuvent se trouver un sous-ensemble de drones et une station sol qui gère le groupe [FB09]. La communication entre groupes doit passer par la station sol. Contrairement à l’architecture lien centralisée, la communication directe inter-drones peut être établie, mais seulement à l’intérieur d’une cellule. Il est aussi possible d’étendre la portée de la mission à travers le déploiement de plusieurs stations. Ces stations peuvent offrir plusieurs liens de commu-nication qui permettent, en cas de dégradation de performance sur un lien donné, d’en utiliser un autre.
Cette architecture se heurte à des limitations en matière de coût de déploiement. En effet, la mise en œuvre coûteuse de cette infrastructure constitue un handicap important dans les lieux où aucune infrastructure de couverture n’est encore mise en place. Si l’utilisation des drones n’est pas fréquente, comme c’est le cas pour les applications de type surveillance lors de catastrophes naturelles, le retour sur investissement peut ne pas être garanti [FB09].
Cette architecture est illustrée par la figure 1.5.b.

Architecture de communication ad hoc

Un réseau ad hoc sans fil (illustré par la figure 1.5.d.) est caractérisé par un ensemble d’entités potentiellement mobiles possédant une ou plusieurs interfaces radio qui mettent en place un réseau de communication de courte durée selon les besoins de l’application. Ces nœuds peuvent être amenés à entrer ou sortir du réseau à tout moment. Le réseau ad hoc sans fil est décentralisé et capable de s’auto-organiser sans la nécessité d’une infrastructure fixe. Si un émetteur n’est pas à portée directe de la machine destination, les informations sont transmises de proche en proche, le long d’un chemin établi et maintenu par le réseau en cas de modification de la topologie. Contrairement au réseau sans fil traditionnel, la zone de service du réseau est la zone géographique dans laquelle les nœuds sont distribués.
Le réseau ad hoc sans fil permet la communication entre deux nœuds qui sont hors de portée directe l’un de l’autre.
Analyse
Dans cette section, listons les avantages de l’architecture ad hoc par rapport aux autres types d’architecture pour une flotte de drones :
— La mise à l’échelle et la reconfiguration agile de la mission exécutée par la flotte de drones : avec l’utilisation d’un système à infrastructure centrale ou par satellite, la zone d’opération sera limitée par la zone de couverture de communication du relais. De plus, en cas de présence d’obstacles, la communication entre les drones peut être bloquée. Grâce à l’architecture ad hoc, il est possible de former une chaine de drones, qui viendrait contourner l’obstacle.
— La fiabilité des communications dans un système aéronautique sans pilote : les drones échangent des messages en temps réel concernant les commandes, la configuration et le déroulement de la mission. Ces messages sont échangés dans un environnement dynamique dans lequel les liens de communication fluctuent et peuvent être coupés. De plus, les drones peuvent être amenés (selon les spécificités de leur mission) à entrer et sortir du réseau de communication. En conséquence, l’aptitude d’auto-organisation d’un réseau ad hoc sans fil permet aux drones de chercher un autre chemin en cas de perte d’un lien.
— La non-nécessité d’une infrastructure dédiée : les réseaux ad hoc sans fil se distinguent des autres types de réseaux par l’absence d’infrastructure centralisée. Les nœuds du réseau sont responsables de l’établissement et du maintien de la connectivité du réseau.
— L’utilisation d’un réseau ad hoc sans fil assure la mobilité et la flexibilité [CHD13]. Grâce à la topologie dynamique, les nœuds mobiles du réseau se déplacent librement et arbitrairement en fonction des objectifs de la mission. Puisque les liens de la topologie peuvent être unidirectionnels ou bidirectionnels, les nœuds peuvent accéder au réseau ou en sortir librement.
— La sécurité d’un réseau ad hoc mobile est distribuée entre les nœuds, contrairement au réseau centralisé et cellulaire. De ce fait, le réseau ne possède pas un unique point vulnérable dans le réseau. La responsabilité de maintenir l’intégrité du réseau est déléguée à chaque nœud du réseau qui, à travers un mécanisme de routage sécurisé peut contrôler l’authentification des messages échangés.
Les différences majeures entre ces différentes architectures sont regroupées dans le tableau 1.3.

Réseau ad hoc de drones

Le réseau ad hoc de drones, connu sous la dénomination anglaise UAV ad hoc NETwork (UAANET) ou encore Flying Ad hoc NETwork (FANET), est une sous-catégorie du réseau mobile MANET. Il s’agit du déploiement d’une flotte de drones et de stations sol à travers un réseau ad hoc sans fil. Les drones collaborent entre eux et avec la(les) station(s) sol pour échanger des données qui peuvent être des données propres au routage (des paquets de contrôle) ou des informations propres au système aérien sans pilote.
Plusieurs dénominations (mentionnées dans le tableau 1.2) de ce type de réseau sont employées dans la littérature. La figure 1.6 illustre un réseau UAANET.
Par ailleurs, il existe plusieurs types de messages échangés entre les drones et la station au sol. Ces différents flux applicatifs sont listés dans le tableau 1.4.
Généralement, ces flux applicatifs comprennent :
— un géoréférencement du drone : ce message est envoyé périodiquement par les drones vers la station de contrôle. Il permet de déterminer la position en temps réel du drone. Ce flux n’exige pas une qualité de service particulière. Il peut supporter quelques pertes ou une latence ;
— un flux tick (ou hearbeat) : c’est un flux de signalement envoyé périodiquement depuis la station sol pour communiquer avec les drones. Il permet de tester l’état de la liaison entre la station sol et le drone. Ce flux n’exige pas une qualité de service stricte et la perte de paquets par intermittence est acceptable ;
— un flux contrôle et commande (C2), et configuration : ce sont les commandes envoyées vers l’autopilote embarqué à bord ou vers la charge utile. Ce type de flux est considéré comme critique puisque il doit être échangé et traité en temps réel. Il nécessite donc un minimum de délai et un maximum de fiabilité des liens de communication.
— un flux de données : tout comme les flux de configuration, ce type de trafic a des exigences strictes en matière de taux de perte et de délai. Il est traditionnellement envoyé depuis le drone le plus éloigné de la station sol et transféré en relais par les membres de la flotte de drones.
Comme nous le détaillerons dans la chapitre 3, le trafic C2 est régi par des réglementations spécifiques garantissant la sécurité et la sûreté d’une mission. Par exemple, en France, la réglementation exige que chaque drone soit en connexion directe avec la station sol à tout instant, à travers des liens à longue portée ou à courte portée [Dro15]. Cela implique que le trafic C2 doive être envoyé depuis une station sol. Il est possible de le relayer entre drones, mais, aujourd’hui, aucune norme ne prend en compte ce genre de déploiement.
Les réseaux UAANET font généralement partie de la famille des réseaux ad hoc mobiles (MANET). Ils ne nécessitent aucune infrastructure fixe et s’appuient sur la collabora-tion des nœuds pour échanger des données. Néanmoins, un réseau UAANET possède des caractéristiques spécifiques qui le différencient des autres types de réseau MANET.B09].

Table des matières

Introduction générale 
1 Architecture de communication pour une flotte de drones 
1.1 Introduction
1.2 Systèmes aéronautiques coopératifs sans pilote
1.2.1 Description fonctionnelle d’un drone
1.2.2 Unmanned Aircraft/Aerial Systems
1.2.2.1 Charge utile
1.2.2.2 Station sol
1.2.3 Drones dans des opérations civiles
1.2.4 Flotte de drones
1.3 Architectures de communication possibles pour une flotte de drones
1.3.1 Architecture de communication centralisée
1.3.2 Architecture de communication par satellite
1.3.3 Architecture de communication réseau cellulaire (Réseau semi-centralisé)
1.3.4 Architecture de communication ad hoc
1.3.5 Réseau ad hoc de drones
1.3.6 Projets de réseau ad hoc de drones
1.4 Protocoles de communication d’un réseau ad hoc de drones
1.4.1 Liaison de données (Medium Access Control)
1.4.2 Niveau réseau : routage dans les réseaux UAANET
1.4.2.1 Protocole hiérarchique
1.4.2.2 Protocole réactif
1.4.2.3 Protocole proactif
1.4.2.4 Protocole géographique
1.5 Discussions et Conclusions
2 Sécurité dans un réseau ad hoc de drones
2.1 Introduction
2.2 Vulnérabilité des réseaux UAANET
2.3 Attaques dans les réseaux UAANET
2.3.1 Description (modèle) des attaquants
2.3.2 Analyse de risques des attaques
2.3.2.1 Attaques au niveau de la couche physique
2.3.2.2 Attaques au niveau de la couche liaison
2.3.3 Attaques liées aux protocoles de routage
2.3.3.1 Attaques pouvant être exécutées durant la phase de découverte de routes
2.3.3.2 Attaques pouvant être exécutées durant la phase de maintenance
2.3.4 Analyse des différentes attaques au niveau réseau
2.4 Solutions existantes et limites
2.4.1 Notions et mécanismes de base de la sécurité
2.4.2 Techniques cryptographiques
2.4.2.1 Cryptographie symétrique et asymétrique
2.4.2.2 Signatures
2.4.2.3 Authentification des messages
2.4.2.4 Fonctions de hachage
2.4.2.5 Certificat
2.4.2.6 Infrastructure à clés publiques
2.4.3 Authentification des noeuds
2.4.4 Systèmes de réputation
2.4.5 Discussions
2.5 Protocoles de routage ad hoc sécurisé existants
2.6 Discussions
2.7 Conclusions
3 Méthodologie de développement d’un logiciel embarqué pour un système de drones 
3.1 Introduction
3.2 Conception de systèmes embarqués critiques
3.2.1 Norme de sûreté
3.2.2 Cycle de vie de développement logiciel
3.2.3 Processus de validation de logiciel dans la norme DO-178B
3.3 Méthodologie orientée modèle
3.3.1 Présentation des différentes étapes
3.3.2 Analyse des modèles
3.3.3 Avantages de l’utilisation de la méthodologie MDD (Model Driven Development)
3.4 Certification d’un système UAS
3.4.1 Apport de l’approche MDD dans la certification UAS
3.5 Choix d’outils pour l’application de la méthodologie MDD
3.5.1 Synthèse sur les chaînes d’outils
3.6 Conclusions
4 Protocole SUAP (Secure UAV Ad hoc routing Protocol) 
4.1 Introduction
4.2 Choix d’un protocole de routage
4.2.1 Protocole expérimental et outil de test de protocole de routage UAANET
4.2.2 Architecture de l’outil de test
4.2.3 Résultats d’évaluation des performances
4.2.3.1 Résultats de connectivité
4.2.4 Délai moyen de ré-établissement d’une route après une perte de connectivité
4.2.4.1 Résultats du délai et de l’overhead
4.3 Protocole SUAP
4.3.1 Modèle réseau et d’attaques considérées dans la conception du protocole SUAP
4.3.2 Description du protocole SUAP
4.3.3 Analyse des solutions existantes
4.3.4 Protocole SAODV
4.3.4.1 Signature numérique dans SAODV
4.3.4.2 Chaîne de hachage dans SAODV
4.3.5 Analyse des vulnérabilités de SAODV
4.3.5.1 Attaque wormhole
4.3.5.2 Attaque avec un seul attaquant
4.3.5.3 État de l’art des solutions contre l’attaque wormhole
4.3.5.4 Synthèse des travaux existants
4.3.6 Proposition d’un mécanisme pour détecter et contrer l’attaque wormhole
4.3.7 Proposition d’un mécanisme pour contrer l’attaque wormhole réalisé par un seul attaquant
4.3.8 Limites du protocole SUAP
4.3.9 Différents formats des paquets de contrôle dans SUAP
4.3.9.1 Format des messages SRREQ
4.3.9.2 Format des messages Secure Hello
4.3.9.3 Format des messages SRERR
4.3.10 Analyse de sécurité du protocole SUAP
4.4 Vérification formelle des propriétés de sécurité du protocole SUAP
4.4.1 Nécessité des procédures de vérification
4.4.2 Choix de l’outil AVISPA
4.4.3 Utilisation de l’outil AVISPA
4.4.4 Cas d’application du protocole SUAP
4.4.4.1 Analyse de spécification du protocole SUAP
4.5 Mise en oeuvre du protocole SUAP
4.5.1 Architecture de l’algorithme SUAP
4.5.2 Modélisation du protocole SUAP
4.5.2.1 Partition de routage
4.5.2.2 Partition de sécurisation
4.5.2.3 Partition d’interfaçage du matériel avec la partition de sécurisation et de routage
4.5.3 Apport de l’approche orientée modèle dans la conception du protocole SUAP
4.5.4 Implémentation du protocole SUAP
4.6 Conclusions
5 Évaluation des performances du protocole SUAP par simulation et par expérimentation réelle 
5.1 Introduction
5.2 Cadre d’expérimentation
5.2.1 Topologies réseau d’études
5.2.1.1 Drones DT18
5.2.1.2 Stations de contrôle
5.2.1.3 Liaison de communication
5.3 Validation de la partition de routage
5.3.1 Topologie de test de routage
5.3.2 Métriques considérées
5.3.3 Résultats obtenus et interprétation
5.3.3.1 Taille d’overhead
5.3.3.2 Stabilité d’une route
5.3.3.3 Durée de ré-établissement d’une route
5.3.3.4 Délai de bout en bout
5.3.3.5 Délai moyen pour l’acheminement des paquets de données utiles
5.3.3.6 Perte de paquet de données
5.3.3.7 Discussion sur la validation de routage
5.4 Validation des fonctions de sécurité du protocole SUAP
5.4.1 Validation de la partition de sécurisation (authentification des messages) en environnement émulé
5.4.1.1 Paramètres d’émulation
5.4.1.2 Métriques considérées
5.4.1.3 Taux de livraison des paquets
5.4.1.4 Délai de bout en bout
5.4.1.5 Overhead
5.4.1.6 Connectivité
5.4.2 Validation de la partition de sécurisation (authentification des messages) en environnement réel
5.4.2.1 Taux de pertes des paquets
5.4.2.2 Overhead
5.4.2.3 Durée de vie moyenne d’une route
5.4.2.4 Pourcentage de routes établies entre station1 et Dr3
5.4.2.5 Délai de bout en bout
5.4.2.6 Évalutation du protocole AODV en environnement réel en présence d’un attaquant blackhole
5.4.3 Validation du mécanisme de détection contre l’attaque wormhole
5.5 Conclusions
6 Conclusions et perspectives 
6.1 Travaux réalisés
6.1.1 Architecture de communication d’une flotte de drones
6.1.2 Besoin en sécurité dans un réseau UAANET
6.1.3 Application d’une méthodologie orientée modèle pour le développement du protocole SUAP
6.1.4 Validation fonctionnelle de la partition de routage et de sécurisation
6.2 Perspectives
6.2.1 Étude de performances complémentaires pour SUAP
6.2.2 Sécurité applicative des échanges en environnement UAANET
6.2.3 Conception d’une infrastructure de gestion de clé adaptée au contexte UAANET
Publications
A Annexe A
A.1 Outils de simulation et d’émulation
A.1.1 Mesure passive
A.1.2 Mesure active
A.1.3 Introduction au framework Virtualmesh
A.1.4 Prise en compte de la mobilité dans le système
B Annexe B
B.1 Vérification formelle avec AVISPA
B.1.1 Quelques outils de vérification formelle existants
B.1.2 Architecture logicielle de l’outil AVISPA
B.1.3 Simulation d’intrus dans AVISPA. Attaque de type confidentialité
Bibliographie 

Télécharger le rapport complet