Mendiboure Leo 2020

THÈSE PRÉSENTÉE
POUR OBTENIR LE GRADE DE
DOCTEUR DE
L’UNIVERSITÉ DE BORDEAUX
ÉCOLE DOCTORALE DE MATHÉMATIQUES ET INFORMATIQUE (EDMI)

SPÉCIALITÉ INFORMATIQUE
Par Léo MENDIBOURE
Distribution géographique de données dans

l’Internet des Véhicules : une approche logicielle et
sécurisée utilisant les réseaux cellulaires
Sous la direction de Francine KRIEF
co-encadrant : Mohamed Aymen CHALOUF
Soutenue le 25/09/2020
Membres du jury :
M. PUJOLLE, Guy Professeur émérite, Sorbonne Université Président

M. MAMMERI, Zoubir Professeur, Université Toulouse III Rapporteur
M. TABBANE, Sami Professeur, Sup’Com Rapporteur
Mme LABIOD, Houda Professeure, Institut Mines-Télécom Examinatrice
Mme ANISS, Hasnaâ Ingénieure de recherche, Université Gustave Eiffel Examinatrice
Mme KRIEF, Francine Professeure, Bordeaux INP Directrice
M. CHALOUF, Mohamed Aymen Maître de Conférences, Université Rennes 1 Co-encadrant
M. DALLA-COSTA, Mathieu Responsable Département Innovation, Akka Technologies Invité
M. HEDHLI, Abdelmename Directeur ERENA, Université Gustave Eiffel Invité
Titre Distribution géographique de données dans l’Internet des Véhicules : une
approche logicielle et sécurisée utilisant les réseaux cellulaires
Résumé Le déploiement de réseaux de communication véhiculaires apparaît au-

jourd’hui comme une solution pertinente pour assurer la sécurité des usagers de la
route et fluidifier le trafic routier. En effet, ces réseaux véhiculaires rendent possible
le déploiement de Systèmes de Transport Intelligents Coopératifs (C-ITS). Grâce aux
applications C-ITS, les véhicules pourraient échanger des informations concernant, par
exemple, l’état de la chaussée ou un freinage d’urgence.
Le fonctionnement de nombreuses applications C-ITS repose sur la distribution géo-
graphique des données : téléchargement coopératif, détection d’obstacles, création de
cartes coopérative, etc. Jusqu’ici, la distribution de ces informations s’est principalement
basée sur des communications directes entre véhicules (véhicule-à-véhicule). Toutefois,
cette approche présente des limites lorsque les données doivent être transmises dans des
zone géographiques vastes : perte de connectivité, perte de paquets, etc. De plus, les ré-
seaux véhiculaires ont évolué, ces dernières années, d’une approche ad hoc vers une
approche centralisée, intégrant les technologies de communications cellulaires. C’est
pourquoi, la distribution géographique de données pourrait s’appuyer sur l’infrastruc-
ture cellulaire, largement déployée et garantissant des performances acceptables.
Aussi, dans cette thèse, nous nous sommes intéressés à la définition d’une solution
efficace et sécurisée pour la distribution géographique de données via l’infrastructure
cellulaire. Pour ce faire, nous avons commencé par proposer une évolution de l’archi-
tecture de communication véhiculaire actuelle. Grâce aux améliorations proposées, le
bon fonctionnement de l’ensemble des applications C-ITS pourrait être garanti. Par la
suite, nous avons défini une solution basée sur une approche logicielle pour la distribu-
tion géographique de données. L’approche considérée permet de surmonter les limites
du protocole actuellement utilisé pour la distribution géographique de données. De
plus, elle garantit une gestion efficace de la mobilité des équipements terminaux. Enfin,
nous avons introduit une nouvelle solution pour la sécurisation des réseaux véhiculaires
définis logiciellement. L’approche proposée, utilisant la technologie Blockchain, vise à
garantir un niveau de sécurité élevé et un passage à l’échelle important.
Mots clés Internet des Véhicules, Distribution géographique, Sécurité, SDN, Block-
chain
iii
Title Geographical data dissemination in the Internet of Vehicles : an efficient and
secure approach based on SDN
Abstract Nowadays, the deployment of vehicular communication networks appears

as an efficient solution to improve both road users safety and road traffic efficiency. In-
deed, vehicular networks could enable the deployment of Cooperative Intelligent Trans-
port Systems (C-ITS). Thanks to C-ITS applications, vehicles could exchange informa-
tion concerning, for example, road conditions or emergency braking.
The operation of many C-ITS applications relies on an efficient geographical disse-
mination of data : cooperative downloading, obstacle detection, cooperative map crea-
tion, etc. So far, this geographical data dissemination has mainly been based on direct
communication between vehicles (vehicle-to-vehicle). However, this approach faces li-
mitations when data must be transmitted over large geographical areas : connectivity
loss, packet loss, etc. In addition, in recent years, vehicular networks have evolved from
an ad hoc approach to a centralized approach, integrating cellular communication tech-
nologies. Therefore, geographical data dissemination could be based on the cellular
network, widely deployed and guaranteeing acceptable performance.
Thus, in this thesis, we focused on the definition of an efficient and secure solu-
tion for cellular-based geographical data dissemination. To achieve that, first of all, we
proposed an evolution of the current vehicular communication architecture. Thanks to
the proposed improvements, the proper functioning of all C-ITS applications could be
guaranteed. Then, we defined a solution, based on a Software Defined approach, to ef-
ficiently distribute data geographically. This approach overcomes the limitations of the
protocol currently used for geographic data dissemination. Moreover, it guarantees an
efficient management of the mobility of terminal devices. Finally, we introduced a new
solution to secure software-defined vehicular networks. The proposed approach, using
the Blockchain technology, aims to guarantee a high level of security and scalability.
Keywords Internet of Vehicles, Geographical data dissemination, Security, SDN,

Blockchain
Unité de recherche
LaBRI (Laboratoire Bordelais de Recherche en Informatique) UMR 5800 - 351 Cours

de la Libération, 33405 Talence
iv
Remerciements
Ces travaux sont le résultat de l’investissement de plusieurs personnes. Aussi, je tiens à

remercier tous ceux qui ont contribué à l’aboutissement de ces recherches que ce soit par un
soutien moral, technique, scientifique, financier, amical ou familial.
v
Table des matières
Résumé iii
Abstract iv
Remerciements v
Table des matières vii
Table des figures xiii
Liste des tableaux xv
Acronymes xvi
Liste des publications xx
1 Introduction 1
1.1 Contexte et Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Organisation de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Vers l’Internet des Véhicules 7

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Présentation générale des réseaux véhiculaires . . . . . . . . . . . . . . . 7
2.2.1 Les caractéristiques des réseaux véhiculaires . . . . . . . . . . . . 7
2.2.2 Des composants principaux . . . . . . . . . . . . . . . . . . . . . 9
2.2.3 De nombreux types de communication . . . . . . . . . . . . . . . 10
2.2.4 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Un objectif : Les Systèmes de Transport Intelligents Coopératifs . . . . . 13
2.3.1 Les C-ITS, raison d’être des réseaux véhiculaires . . . . . . . . . . 13
2.3.2 Les applications C-ITS . . . . . . . . . . . . . . . . . . . . . . . . 13
vii
TABLE DES MATIÈRES
2.3.2.1 Des applications nombreuses et variées . . . . . . . . . 14

2.3.2.2 Des besoins diversifiés . . . . . . . . . . . . . . . . . . . 15
2.3.3 Deux technologies d’accès principales . . . . . . . . . . . . . . . 18
2.3.3.1 ETSI ITS-G5 . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.3.2 Réseaux cellulaires . . . . . . . . . . . . . . . . . . . . . 20
2.3.3.2.1 LTE-V2X . . . . . . . . . . . . . . . . . . . . . . 21
2.3.3.2.2 5G NR . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.4 Une architecture C-ITS standardisée . . . . . . . . . . . . . . . . 24
2.3.5 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4 Une évolution nécessaire du paradigme de communication . . . . . . . . 27
2.4.1 L’approche d’origine, les réseaux véhiculaires ad hoc . . . . . . . 27
2.4.1.1 Le principe des réseaux véhiculaires ad hoc . . . . . . . 27
2.4.1.2 Les limites des réseaux véhiculaires ad hoc . . . . . . . 28
2.4.2 Le présent et l’avenir : l’Internet des Véhicules . . . . . . . . . . . 30
2.4.3 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3 Une nouvelle architecture de communication pour l’Internet des Véhicules 33

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.2 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3 Solutions technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.1 SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.1.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.1.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.1.3 Bénéfices . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.2 NFV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.2.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.2.2 Bénéfices . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.3 Edge computing . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3.3.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3.3.2 Bénéfices . . . . . . . . . . . . . . . . . . . . . . . . . . 47
viii
TABLE DES MATIÈRES
3.3.4 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.4.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.4.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3.4.3 Bénéfices . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.5 Données massives et Intelligence Artificielle . . . . . . . . . . . . 51
3.3.5.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.5.2 Bénéfices . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.6 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4 Architectures IoV existantes . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.1 Amélioration du plan de gestion . . . . . . . . . . . . . . . . . . 53
3.4.2 Amélioration du plan de contrôle et de données . . . . . . . . . . 55
3.4.3 Amélioration du plan de sécurité et de respect de la vie privée . . 57
3.4.4 Comparaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.4.5 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.5 Une nouvelle architecture pour l’IoV . . . . . . . . . . . . . . . . . . . . 61
3.5.1 Présentation globale . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.5.2 Combinaison des améliorations existantes . . . . . . . . . . . . . 62
3.5.2.1 Bénéfices . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.5.2.2 Mise en application . . . . . . . . . . . . . . . . . . . . 65
3.5.3 Intégration de la technologie Blockchain dans le plan de sécurité
et de respect de la vie privée . . . . . . . . . . . . . . . . . . . . . 65
3.5.3.1 Bénéfices . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.5.4 Définition d’un plan de connaissance . . . . . . . . . . . . . . . . 68
3.5.4.1 Bénéfices . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.5.5 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4 Une approche logicielle performante pour la distribution géographique des

données 73
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.2 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
ix
TABLE DES MATIÈRES
4.2.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.2.2 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.3 Solutions existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.3.1 Traitement des données . . . . . . . . . . . . . . . . . . . . . . . 79
4.3.2 Distribution des données . . . . . . . . . . . . . . . . . . . . . . . 80
4.3.3 Échanges entre plan de contrôle et équipements réseau . . . . . . 81
4.3.4 Gestion des tables de flux . . . . . . . . . . . . . . . . . . . . . . 82
4.3.5 Comparaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.3.6 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.4 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.4.1 Environnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.4.2 Scénario de distribution géographique . . . . . . . . . . . . . . . 88
4.4.3 Prédiction de mobilité . . . . . . . . . . . . . . . . . . . . . . . . 88
4.4.4 Estimation du niveau de charge des stations de base . . . . . . . 90
4.4.5 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.5 Une approche logicielle performante pour la distribution géographique
des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.5.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.5.2 Définition des zones de distribution géographique . . . . . . . . . 93
4.5.3 Sélection des stations de base réceptrices . . . . . . . . . . . . . . 94
4.5.3.1 Estimation de la durée de connexion entre les stations
de base et les équipements terminaux . . . . . . . . . . 94
4.5.3.2 Prise en compte du niveau de charge des stations de
base dans la sélection des destinataires . . . . . . . . . 96
4.5.4 Automatisation des transitions entre états . . . . . . . . . . . . . 98
4.5.5 Point d’équilibre entre canal de contrôle et tables de flux . . . . . 102
4.5.6 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.6 Évaluation des performances . . . . . . . . . . . . . . . . . . . . . . . . 104
4.6.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.6.2 Environnement de test . . . . . . . . . . . . . . . . . . . . . . . . 105
4.6.3 Estimation de la durée de connexion . . . . . . . . . . . . . . . . 108
4.6.4 Sélection des stations de base destinataires . . . . . . . . . . . . 109
4.6.5 Gestion des transitions entre états . . . . . . . . . . . . . . . . . 111
x
TABLE DES MATIÈRES
4.6.6 Politique de pré-déploiement des règles de flux . . . . . . . . . . 113

4.6.7 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.7 Discussion : Bénéfices du plan de connaissance pour la distribution géo-
graphique de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.7.1 Bénéfices du plan de connaissance . . . . . . . . . . . . . . . . . 116
4.7.2 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5 Une sécurisation des réseaux SD-IoV s’appuyant sur la Blockchain 121

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.2 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.2.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.2.2 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.3 Solutions existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.3.1 Sécurisation de l’interface sud . . . . . . . . . . . . . . . . . . . . 127
5.3.2 Sécurisation de l’interface est/ouest . . . . . . . . . . . . . . . . 129
5.3.3 Sécurisation de l’interface nord . . . . . . . . . . . . . . . . . . . 130
5.3.4 Comparaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
5.3.5 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
5.4 Une sécurisation des réseaux SD-IoV s’appuyant sur la Blockchain . . . . 133
5.4.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.4.2 Architecture Blockchain proposée . . . . . . . . . . . . . . . . . . 135
5.4.3 Sécurisation des communications . . . . . . . . . . . . . . . . . . 138
5.4.3.1 Modèle d’enregistrement des éléments SD-IoV . . . . . 138
5.4.3.2 Authentification et révocation . . . . . . . . . . . . . . . 140
5.4.3.3 Contrôle d’accès . . . . . . . . . . . . . . . . . . . . . . 143
5.4.4 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
5.5 Évaluation des performances . . . . . . . . . . . . . . . . . . . . . . . . 146
5.5.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
5.5.2 Environnement de test . . . . . . . . . . . . . . . . . . . . . . . . 147
5.5.3 Bénéfices de l’architecture Blockchain proposée . . . . . . . . . . 148
5.5.4 Impact de l’authentification/révocation inter-sous-réseaux Block-
chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
xi
TABLE DES MATIÈRES
5.5.5 Impact du contrôle d’accès . . . . . . . . . . . . . . . . . . . . . . 155

5.5.6 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
5.6 Cas d’étude : Estimation du nombre optimal de sous-réseaux . . . . . . . 157
5.6.1 Estimation du nombre optimal de sous-réseaux . . . . . . . . . . 157
5.6.2 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
5.7 Discussion : Bénéfices du plan de connaissance pour la sécurisation des
communications SD-IoV . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
5.7.1 Bénéfices du plan de connaissance . . . . . . . . . . . . . . . . . 163
5.7.2 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
5.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
6 Conclusion et perspectives 168

6.1 Principales contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
6.2 Perspectives et nouveaux défis . . . . . . . . . . . . . . . . . . . . . . . . 169
Bibliographie 173
Annexes 200
A. Architecture de référence ETSI ISG NFV . . . . . . . . . . . . . . . . . . 200
B. Comparaison des principales technologies de communication véhiculaires 202
C. Comparaison des différentes approches d’Edge Computing . . . . . . . . 203
D. Architecture ETSI de référence pour la technologie MEC . . . . . . . . . 205
E. Cas d’utilisation de GeoNet : Dissémination géographique des données
assistée par l’infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . 207
F. Procédure de handover dans les réseaux 5G définis logiciellement . . . . 209
G. Fonctionnement du protocole OpenFlow . . . . . . . . . . . . . . . . . . 211
H. SDN : Plan de données avec états . . . . . . . . . . . . . . . . . . . . . . 213
I. Environnement de simulation considéré . . . . . . . . . . . . . . . . . . 216
J. Définition d’un plan de connaissance global . . . . . . . . . . . . . . . . 218
xii
Table des figures
2.1 Principaux types de communication V2X . . . . . . . . . . . . . . . . . . 12

2.2 Couche protocolaire ITS-G5 . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Nouveaux modes de communication introduits pour les réseaux LTE-V2X 22
2.4 Architecture de référence C-ITS . . . . . . . . . . . . . . . . . . . . . . . 25
2.5 Des VANet à l’IoV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1 Architecture de communication SDN : Application aux réseaux

de communication véhiculaires 1 . . . . . . . . . . . . . . . . . . . . . . 42
3.2 Différentes approches d’informatique en périphérie du réseau . . . . . . 47
3.3 Architecture de la Blockchain 2 . . . . . . . . . . . . . . . . . . . . . . . 50
3.4 Architecture C-ITS combinant l’ensemble des améliorations proposées . 59
3.5 Architecture C-ITS proposée . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.1 Représentation des réseaux 5G définis logiciellement . . . . . . . . . . . 87

4.2 Scénario de distribution géographique considéré . . . . . . . . . . . . . 89
4.3 Exemple de mobilité d’un équipement terminal . . . . . . . . . . . . . . 90
4.4 Comparaison des mécanismes d’estimation de la durée de connexion . . 108
4.5 Comparaison des mécanismes de transition entre stations de base . . . . 112
4.6 Evaluation de la politique de pré-déploiement proposée . . . . . . . . . . 115
5.1 Architecture Blockchain proposée . . . . . . . . . . . . . . . . . . . . . . 136

5.2 TLS : Protocole handshake basé sur la Blockchain . . . . . . . . . . . . . 141
5.3 Évaluation des bénéfices de l’architecture proposée . . . . . . . . . . . . 150
5.4 Évaluation de l’impact des mécanismes d’authentification/révocation
proposés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
5.5 Évaluation de l’impact du mécanisme de contrôle d’accès proposé . . . . 156
7.1 Architecture ETSI ISG NFV 3 . . . . . . . . . . . . . . . . . . . . . . . . . 200

7.2 Architecture ETSI GS MEC . . . . . . . . . . . . . . . . . . . . . . . . . . 205
7.3 Exemple de dissémination géographique des données . . . . . . . . . . . 207
xiii
TABLE DES FIGURES
7.4 Représentation du fonctionnement du handover pour les réseaux 5G dé-

finis logiciellement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
7.5 Procédure des gestion des paquets . . . . . . . . . . . . . . . . . . . . . 212
7.6 Plan de données avec états . . . . . . . . . . . . . . . . . . . . . . . . . . 213
7.7 Tables utilisées par le plan de données avec état . . . . . . . . . . . . . . 214
7.8 Environnement de simulation considéré . . . . . . . . . . . . . . . . . . 216
xiv
Liste des tableaux
2.1 Principales applications des réseaux véhiculaires . . . . . . . . . . . . . . 15

2.2 Identification des besoins des principales applications V2X . . . . . . . . 17
2.3 Architectures VANet et IoV : Comparaison . . . . . . . . . . . . . . . . . 28
3.1 Comparaison des différentes évolutions architecturales proposées . . . . 58
4.1 Comparaison des travaux proposant une approche logicielle pour la dis-
tribution de données dans l’environnement véhiculaire . . . . . . . . . . 83
4.2 Paramètres de simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.3 Évaluation du processus de sélection des stations de base destinataires . 110
5.1 Comparaison des approches utilisant la Blockchain pour la sécurisation

des interfaces SD-IoV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
7.1 Comparaison technique des différentes technologies d’accès . . . . . . . 202

7.2 Comparaison des différentes approches d’Edge Computing . . . . . . . . 203
7.3 Applications du plan de connaissance aux propositions introduites dans
les chapitres 4 et 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
xv
Acronymes
Acronyme Signification
Application Programming Interface
API
(Interface de Programmation)
BC Blockchain
Base Station
BS
(Station de Base)
Basic Transport Protocol
BTP
(Protocole de Transport Basique)
Cumulative Distribution Function
CDF
(Fonction de Distribution Cumulative)
Control an Data Plane
CDP
(Plan de Contrôle et de Données)
Cooperative Intelligent Transportation Systems
C-ITS
(Systèmes de Transport Intelligents Coopératifs)
Decentralized Congestion Control
DCC
(Contrôle de Congestion Décentralisé)
Distributed Mobility Aware
DMA
(Distribué Sensible à la Mobilité)
Dedicated Short Range Technologies
DSRC
(Communications dédiées à courte portée)
Device-to-Device
D2D
(Objet-à-Objet)
Edge Computing
EC
(Informatique en périphérie du réseau)
European Telecommunications Standards Institute
ETSI
(Institut Européen des Normes de Télécommunication)
Hardware Security Module
HSM
(Module Matériel de Sécurité)
Internet of Vehicules
IoV
(Internet des Véhicules)
Infrastructure-to-Infrastructure
I2I
(Infrastructure-à-Infrastructure)
xvi
Knowledge Plane
KP
(Plan de connaissance)
Load Aware and Mobility Aware Pre-deployment
LAMAP
(Pré-déploiement Sensible à la Mobilité et Sensible au niveau de Charge)
Mobility Aware
MA
(Sensible à la Mobilité)
Mobility Aware Pre-deployment
MAP
(Pré-déploiement Sensible à la Mobilité)
Mobile Ad hoc Network
MANet
(Réseau Mobile Ad hoc)
Multi-Access Edge Computing
MEC
ou Mobile Edge Computing
Man-In-The-Middle attack
MITM
(attaque de l’Homme Du Milieu)
Management Plane
MP
(Plan de Gestion)
Network Function Virtualization
NFV
(Virtualisation des Fonctions Réseau)
Non-uniform Load
NL
(Charge Non-uniforme)
On Board Unit
OBU
(Unité embarquée)
Occupied SDN controller
Oc
(Niveau d’occupation élevé du Contrôleur SDN)
Occupied SDN flow tables
Of
(Niveau d’occupation élevé des Tables de flux SDN)
Occupied SDN flow tables and Controller
Ofc
(Niveau d’occupation élevé des Tables de flux et du Contrôleur SDN)
ONF Open Networking Foundation
Open Systems Interconnection
OSI
(Interconnexion des Systèmes Ouverts)
Physical Resource Block
PRB
(Bloc de Ressource Physique)
xvii
Policy-LAMAP
P-LAMAP
(LAMAP avec Politique)
Resource Block Utilization Rate
RBUR
(Ratio d’Utilisation de Blocs de Ressources)
Road Side Unit
RSU
(Unité de bord de route)
Software Defined Networking
SDN
(Réseaux Définis logiciellement)
Software Defined-Internet of Vehicules
SD-IoV
(Internet des Véhicules Défini logiciellement)
Security and Privacy Plane
SPP
(Plan de Sécurité et de Respect de la Vie Privée)
Ternary Content Addressable Memory
TCAM
(Mémoire Ternaire Adressable par le Contenu)
Transport Layer Security
TLS
(Sécurité Couche Transport)
Uniform Load
UL
(Charge Uniforme)
Vehicular Ad hoc Networks
VANet
(Réseau Véhiculaire Ad hoc)
Vehicle-to-Building
V2B
(Véhicule-à-Bâtiment)
Vehicle-to-Cloud
V2C
(Véhicule-à-Cloud)
Vehicle-to-Grid
V2G
(Véhicule-à-Réseau électrique intelligent)
Vehicle-to-Infrastructure
V2I
(Véhicule-à-Infrastructure)
Vehicle-to-Person
V2P
(Véhicule-à-Personne)
Vehicle-to-Network
V2N
(Véhicule-à-Réseau)
Vehicle-to-Vehicle
V2V
(Véhicule-à-Véhicule)
xviii
Vehicle-to-Everything
V2X
(Véhicule-à-Tout)
Without-policy-LAMAP
W-LAMAP
(LAMAP sans Politique)
xix
Liste des publications
A. Chapitres de livres
Leo Mendiboure, Mohamed-Aymen Chalouf, et Francine Krief. "Vers de nouvelles
architectures intelligentes pour l’Internet des Véhicules." Chapitre 8, Ouvrage Ges-
tion et Contrôle Intelligents des Réseaux, Badr Benmammar, Collection ISTE
(2020)
Leo Mendiboure, Mohamed-Aymen Chalouf, et Francine Krief. "Towards new in-

telligent architectures for the Internet of Vehicles." Chapitre 8, Ouvrage Intelligent
Network Management and Control, Badr Benmammar, Wiley (2020)
Leo Mendiboure, Mohamed-Aymen Chalouf, et Francine Krief. "Gestion dyna-

mique des identités et des accès dans l’IoT : une approche basée sur la blockchain."
Chapitre 9, Ouvrage La gestion et le contrôle intelligents des performances et
de la sécurité dans l’IoT, Mohamed-Aymen Chalouf, Collection ISTE (A Paraître)
B. Journaux internationaux
Leo Mendiboure, Mohamed-Aymen Chalouf, and Francine Krief. "Edge computing
based applications in vehicular environments : Comparative study and main issues."
Journal of Computer Science and Technology 34.4 (2019) : 869-886.
Leo Mendiboure, Mohamed-Aymen Chalouf, and Francine Krief. "Survey on

blockchain-based applications in internet of vehicles." Elsevier Computers & Elec-
trical Engineering 84 (2020) : 106646.
Leo Mendiboure, Mohamed-Aymen Chalouf, and Francine Krief. "Load-aware and

Mobility-aware Flow Rules Management in Software Defined Vehicular Access Net-
works." IEEE Access (A Paraître, 2020).
C. Conférences internationales
Leo Mendiboure, Mohamed Aymen Chalouf, and Francine Krief. "Towards a
blockchain-based SD-IoV for applications authentication and trust management."
xx
The 5th International Conference on Internet of Vehicles. Springer, Cham,
2018.
Leo Mendiboure, Mohamed Aymen Chalouf, and Francine Krief. "Towards a 5G

vehicular architecture." The 14th International Workshop on Communication
Technologies for Vehicles. Springer, Cham, 2019.
Leo Mendiboure, Mohamed Aymen Chalouf, and Francine Krief. "A SDN-Based
Pub/Sub Middleware for Geographic Content Dissemination in Internet of Vehicles."
2019 IEEE 90th Vehicular Technology Conference (VTC2019-Fall). IEEE, 2019.
Leo Mendiboure, Mohamed Aymen Chalouf, and Francine Krief. "A Scalable
Blockchain-based Approach for Authentication and Access Control in Software De-
fined Vehicular Networks." 29th International Conference on Computer Com-
munication and Networks, ICCCN 2020. IEEE, 2020.
xxi
Chapitre 1
Introduction
1.1 Contexte et Motivations

Chaque année, plusieurs dizaines de millions de personnes sont tuées ou blessées
dans des accidents routiers. Face à ce constat, la conception d’outils permettant d’assurer
la sécurité des usagers de la route est apparue comme essentielle.
Avec l’avènement des réseaux de communication sans fil et la prolifération des ter-
minaux mobiles, le développement de réseaux de communications véhiculaires s’est
présenté comme une solution potentielle. En effet, en établissant des communications
entre véhicules, il devient possible de garantir une transmission efficace d’informa-
tions, concernant l’état de la route, la présence d’un obstacle ou un freinage brusque.
Aussi, basé sur ces réseaux véhiculaires, un nouveau paradigme a émergé : les Systèmes
de Transport Intelligents Coopératifs (C-ITS, Cooperative Intelligent Transportation Sys-
tems). Ceux-ci, grâce aux communications véhiculaires, doivent permettre d’améliorer
la sécurité routière, la fluidité du trafic et le confort des usagers de la route.
Pour le déploiement des réseaux de communication véhiculaires, une architecture
entièrement décentralisée, basée sur des communications directes entre véhicules, a
tout d’abord été considérée. Ce réseau décentralisé ad hoc (VANet, Vehicular Ad Hoc
Network) devait garantir une transmission rapide des informations entre véhicules voi-
sins, sans nécessiter le déploiement d’une infrastructure de bord de route coûteuse.
Toutefois, cette architecture décentralisée présentait différentes limites. Tout d’abord,
elle ne supportait qu’une seule technologie d’accès radio, complexifiant le déploiement
des applications C-ITS. Ensuite, elle n’offrait qu’une connectivité Internet limitée, ne ga-
rantissant pas un traitement efficace et centralisé des données. Enfin, elle ne permettait
pas aux véhicules d’interagir avec leur environnement : piétons, cyclistes, caméras de
surveillance, etc.
Aussi, les réseaux véhiculaires ont évolué vers une architecture centralisée, ou hy-
bride : l’Internet des Véhicules (IoV, Internet of Vehicles). Cette architecture combine
1
1. Introduction
les bénéfices d’une approche ad hoc (faible latence), et les bénéfices d’une approche
centralisée (traitement efficace des données, interopérabilité). L’IoV se base sur trois
idées principales. Tout d’abord, différentes technologies de communications sont inté-
grées : ITS-G5, LTE-V2X, 5G NR, etc. Ensuite, les réseaux véhiculaires sont inclus dans
l’Internet des Objets, permettant l’établissement de communications entre véhicules et
objets environnants. Enfin, un traitement optimal des données devient possible grâce à
la connectivité Internet permanente offerte par l’IoV. Avec ces évolutions, l’IoV ouvre les
réseaux véhiculaires aux applications commerciales, ce qui constitue un enjeu majeur
pour leur adoption.
Le fonctionnement de certaines de ces applications commerciales, et de nombreuses
applications C-ITS, repose sur une distribution géographique de données efficace. En ef-
fet, le téléchargement coopératif de données, la détection d’obstacles ou encore la créa-
tion coopérative de cartes dépendent d’un échange de données entre des équipements
terminaux situés dans une même zone géographique. Avec les réseaux véhiculaires ad
hoc, cette distribution géographique de données était uniquement basée sur des com-
munications directes entre véhicules. Or, lorsque les données doivent être transmises
dans de vastes zones géographiques, ces communications directes peuvent présenter
des limites : rupture de connectivité et perte de paquets.
Aussi, l’utilisation de l’infrastructure de bord de route apparaît comme une alter-
native pour cette diffusion des données dans de vastes zones géographiques. Les ré-
seaux de communications cellulaires (LTE-V2X, 5G NR), intégrés à l’architecture IoV,
pensés pour supporter les communications véhiculaires, et déployés à large échelle, ap-
paraissent notamment comme une solution pertinente. Ils pourraient, en effet, garantir
une distribution géographique fiable et des performances acceptables (latence, bande
passante, perte de paquets).
1.2 Problématique
Différents travaux se sont intéressés à l’utilisation des réseaux cellulaires pour la
distribution géographique de données dans l’environnement IoV. Néanmoins, d’impor-
tantes problématiques subsistent [ZADZ+ 19, JCL19] :
— une architecture de communication IoV inadaptée aux besoins des applica-
tions C-ITS : la mise en place d’échanges entre véhicules, objets connectés, et
infrastructure de bord de route, s’appuie sur l’architecture de communication IoV
2
1. Introduction
sous-jacente. Aussi, cette architecture doit garantir le bon fonctionnement des ap-
plications C-ITS. Or, l’architecture de référence actuelle est confrontée à diffé-
rentes problématiques liées à la gestion des ressources, à la reconfiguration du
réseau ou encore au support de plateformes hétérogènes. Aussi, pour garantir un
fonctionnement optimal des applications C-ITS, la définition d’une nouvelle archi-
tecture de communication est nécessaire ;
— une distribution géographique des données coûteuse : l’infrastructure cellu-

laire, au delà de la distribution géographique de données, supporte un nombre im-
portant d’applications (C-ITS, multimédia, machine-à-machine). Par conséquent,
pour garantir des performances élevées (latence, bande passante, perte de pa-
quets), les ressources à disposition doivent être utilisées de façon optimale. Or, le
protocole intégré à l’architecture IoV pour la distribution géographique des don-
nées véhiculaires, appelé GeoNet, ne permet qu’un traitement peu efficace et une
distribution statique des informations. Aussi, pour garantir une utilisation opti-
male de l’infrastructure cellulaire, la définition d’une nouvelle solution pour la
distribution géographique des données est nécessaire ;
— une sécurisation insuffisante des communications : la sécurisation des commu-

nications est un enjeu important pour les réseaux véhiculaires. En effet, l’échange
d’informations doit notamment permettre d’assurer la sécurité des usagers de la
route. Sécuriser ces échanges (authentification, contrôle d’accès) est donc essen-
tiel. Or, les solutions proposées jusqu’ici présentent différentes limites dont le
manque de passage à l’échelle, un coût de déploiement important et un niveau de
sécurité insuffisant. C’est pourquoi, le développement de nouveaux mécanismes
d’authentification et de contrôle d’accès pour les réseaux véhiculaires est néces-
saire.
1.3 Contributions
Afin de permettre une distribution géographique de données via l’infrastructure cel-
lulaire efficace, les travaux menés dans le cadre de cette thèse ont visé à offrir une
solution aux problèmes identifiés ci-dessus. Ainsi, nous avons oeuvré à :
— la définition d’une nouvelle architecture de communication IoV : comme nous

l’avons noté, l’architecture de communication IoV de référence présente diffé-
3
1. Introduction
rentes limites, tant en terme de gestion que de contrôle et de sécurité. Pour sur-
monter ces limitations, différentes solutions technologiques pourraient être consi-
dérées : réseaux logiciels, virtualisation, intelligence artificielle, etc. Aussi, en nous
basant sur une analyse des bénéfices de ces solutions technologiques, nous avons
proposé différentes évolutions de l’architecture IoV de référence devant permettre
de répondre aux limites actuelles ;
— la définition et l’implémentation d’une approche logicielle pour la distribu-

tion géographique de données : comme nous l’avons noté, le protocole utilisé
pour la distribution géographique de données via l’infrastructure cellulaire est coû-
teux en ressources et peu flexible. Pour surmonter ces limites, la définition d’une
approche logicielle parait pertinente. En effet, elle pourrait garantir un niveau de
dynamicité et de programmabilité élevé ainsi qu’une prise de décision centralisée.
Aussi, partant des limites actuelles, nous avons proposé une approche logicielle
performante pour la distribution géographique de données. Au travers de diffé-
rentes expérimentations, les bénéfices de notre solution ont pu être démontrés,
tant en terme d’utilisation des ressources que de flexibilité et de latence ;
— la définition et l’implémentation d’une approche basée sur la Blockchain pour

la sécurisation des échanges : comme nous l’avons noté, la sécurisation des com-
munications est essentielle pour les réseaux véhiculaires. Pour cette sécurisation,
la technologie Blockchain pourrait être utilisée. En effet, elle pourrait permettre de
garantir un niveau de sécurité élevé, un meilleur passage à l’échelle et de faibles
coûts. Aussi, en nous plaçant dans le cadre des réseaux définis logiciellement, nous
avons proposé une solution basée sur cette technologie, pour l’authentification et
le contrôle d’accès des éléments IoV. Les expérimentations réalisées ont permis de
démontrer les bénéfices de l’approche proposée, notamment en terme de passage
à l’échelle et de sécurité (contrôle d’accès).
1.4 Organisation de la thèse

Cette thèse est organisée comme suit :
— Chapitre 2 "Vers l’Internet des Véhicules" : dans ce premier chapitre, nous pré-
sentons l’état actuel des réseaux véhiculaires. Pour ce faire, nous introduisons, tout
d’abord, les principales caractéristiques des communications véhiculaires. Par la
4
1. Introduction
suite, nous mettons en avant le principal moteur des réseaux de communications

véhiculaires : les C-ITS. Enfin, nous justifions l’évolution des réseaux véhiculaires
ad hoc vers l’IoV ;
— Chapitre 3 "Une nouvelle architecture de communication pour l’Internet des

Véhicules " : dans ce chapitre, nous introduisons notre première contribution :
une évolution de l’architecture de référence C-ITS devant permettre l’avènement
de l’IoV. Pour ce faire, nous identifions, tout d’abord, les limites actuelles de l’archi-
tecture de référence. Par la suite, nous présentons les principales solutions techno-
logiques existantes. Puis, nous mettons en avant les améliorations de l’architecture
de référence déjà proposées dans la littérature et identifions leurs limites. Enfin,
partant des points non considérés, nous proposons une nouvelle architecture IoV.
Celle-ci se base, notamment, sur la définition d’un plan de connaissance et l’inté-
gration de la technologie Blockchain ;
— Chapitre 4 "Une approche logicielle performante pour la distribution géogra-

phique des données" : dans ce chapitre, nous introduisons notre seconde contri-
bution : une approche logicielle pour la distribution géographique de données via
l’infrastructure cellulaire. Pour ce faire, nous commençons par identifier les limites
du protocole actuellement intégré à l’architecture de référence (GeoNet). Nous
mettons, également, en avant les bénéfices d’une approche logicielle pour cette
distribution géographique. De plus, nous ciblons les points devant être considérés
pour offrir une approche logicielle performante dans un environnement mobile.
Par la suite, nous présentons les travaux existants et identifions leurs limites. Puis,
afin d’y répondre, nous proposons une nouvelle solution pour la distribution géo-
graphique de données. Celle-ci repose, notamment, sur la sélection dynamique
des stations de base destinataires et sur l’utilisation de machine d’états. Enfin,
nous comparons les performances de la solution proposée à celles des travaux
existants ;
— Chapitre 5 "Une sécurisation des réseaux SD-IoV s’appuyant sur la Block-

chain" : dans ce chapitre, nous introduisons notre troisième contribution : une
approche basée sur la Blockchain visant à sécuriser les réseaux véhiculaires définis
logiciellement. Pour ce faire, nous commençons par identifier les principaux vec-
teurs d’attaques pour les réseaux véhiculaires définis logiciellement. Par la suite,
5
1. Introduction
nous présentons les travaux existants et identifions leurs limites. Puis, afin d’y ré-
pondre, nous proposons une nouvelle solution. Celle-ci s’appuie, notamment, sur
la définition d’une nouvelle architecture Blockchain et la définition de mécanismes
d’authentification et de contrôle d’accès efficaces. Par la suite, nous comparons les
performances de la solution proposée à celles des travaux existants. Enfin, nous
démontrons la faisabilité de notre approche en nous penchant sur la question de
son déploiement ;
— Chapitre 6 "Conclusion et perspectives" : dans ce chapitre, nous présentons une
conclusion générale des travaux décrits dans ce manuscrit. Nous proposons, égale-
ment, quelques perspectives pour de futurs travaux de recherche s’inscrivant dans
la continuité de cette thèse.
6
Chapitre 2
Vers l’Internet des Véhicules
2.1 Introduction
Les travaux menés dans le cadre de cette thèse portent sur la distribution de données
dans les réseaux véhiculaires. Ce chapitre vise donc à offrir une vision d’ensemble de
l’environnement véhiculaire. Pour ce faire, les principales caractéristiques des réseaux
véhiculaires sont tout d’abord introduites (cf. Section 2.2). Dans un second temps, les
Systèmes de Transport Intelligents Coopératifs (C-ITS, Cooperative Intelligent Transpor-
tation Systems), la principale raison d’être des réseaux véhiculaires, sont présentés. Les
applications, les technologies et l’architecture de référence de ces C-ITS sont également
définis (cf. Section 2.3). Enfin, l’évolution actuelle de l’architecture de communication
véhiculaire, d’une architecture ad hoc vers une approche centralisée, est mise en avant
(cf. Section 2.4).
2.2 Présentation générale des réseaux véhiculaires

Dans cette section, les principales caractéristiques (cf. Section 2.2.1), les principaux
composants (cf. Section 2.2.2) et les principaux types de communication (cf. Section
2.2.3) des réseaux véhiculaires sont présentés.
2.2.1 Les caractéristiques des réseaux véhiculaires

Les réseaux véhiculaires, avant tout basés sur des communications directes entre
véhicules, possèdent certaines caractéristiques propres aux réseaux de communication
mobiles ad hoc (MANET, Mobile Ad Hoc Network). On peut notamment citer le broadcast
omnidirectionnel, les liaisons sans fil à débit variable, la bande passante limitée, la
topologie dynamique, la courte portée de transmission, la densité variable des noeuds
et la sécurité physique limitée [CA14].
Toutefois ces réseaux présentent également certaines caractéristiques intrinsèque-
ment liées au fait que les noeuds sont des véhicules :
7
2. Des réseaux véhiculaires ad hoc à l’Internet des Véhicules
— une topologie réseau hautement dynamique : de part le déplacement à grande

vitesse des véhicules, la topologie réseau connaît nécessairement de fréquentes
modifications ;
— des déconnexions fréquentes : de part le déplacement à grande vitesse des véhi-
cules, les ruptures de liens de communication entre véhicules ou entre véhicules
et infrastructure sont fréquentes ;
— un nombre important de noeuds : de part le nombre important de véhicules
en circulation, les réseaux véhiculaires doivent permettre un passage à l’échelle
importante ;
— une densité réseau variable : le nombre de véhicules dans une zone donnée
dépend de différents facteurs tels que le moment de la journée (heure d’affluence
ou non), la position géographique (centre ville, proche banlieue, campagne) ou le
type de route (route départementale, autoroute) ;
— des modèles de mobilité spécifiques : bien que la topologie réseau soit haute-
ment dynamique, les véhicules suivent généralement le tracé des routes et res-
pectent les limitations de vitesse. Aussi, il est possible de définir des modèles de
mobilité permettant de déterminer de façon fiable la position future des véhicules ;
— des garanties de bande passante et de faible latence nécessaires : de nom-
breuses applications véhiculaires, notamment destinées à la sécurité routière, né-
cessitent de faibles délais de transmission (cf. Section 2.3.2.2). Sans cela, le bon
fonctionnement de ces applications ne pourra pas être garanti. Ceci dans des cas
extrêmes pourrait occasionner des accidents. De même, une transmission d’un
nombre important d’informations doit être possible lorsque cela est nécessaire
(prévention de collision, détection d’un obstacle, etc.) ;
— une disponibilité importante en énergie, en capacité de stockage et de cal-
cul : les véhicules offrent une quantité d’énergie, une capacité de calcul et un
espace de stockage supérieurs à ceux des objets mobiles courants. Aussi, bien que
le développement de solutions faiblement consommatrices d’énergie soit un su-
jet d’actualité, les véhicules supportent un nombre d’opérations et de traitement
locaux plus important ;
— l’existence de zones d’intérêt : pour nombre d’applications véhiculaires, les in-
formations générées sont ne sont pertinentes que dans une zone géographique
8
donnée (cf. Section 2.3.2.2). C’est notamment le cas des informations concernant
l’état de la chaussée, un freinage brusque ou le téléchargement coopératif de don-
nées. L’existence de zones d’intérêt est donc une caractéristique importante des
applications véhiculaires.
2.2.2 Des composants principaux

L’idée première des réseaux véhiculaires est d’assurer la sécurité routière grâce à une
transmission rapide d’informations aux véhicules environnants. Aussi, deux composants
ont été spécialement conçus pour permettre ces communications 1 :
— l’unité embarquée (OBU, On Board Unit) : embarqué à l’intérieur des véhicules,

ce composant permet aux véhicules d’établir des communication avec les équi-
pements terminaux et équipements réseau alentours. L’OBU est également utilisé
pour traiter les informations remontées par les capteurs des véhicule. L’OBU est
composé de différents éléments, notamment, des capteurs (GPS, LIDAR, etc.), une
interface (antenne) réseau et un module de contrôle central ;
— l’unité de bord de route (RSU, Road Side Unit) : il s’agit d’un point d’accès sans fil
fixe, positionné le long des routes (intersection, parking) et spécifiquement conçu
pour les communications véhiculaires. Le RSU a deux rôle essentiels. Le premier
est de diffuser localement les informations (aux véhicules qui lui sont directement
connectés et aux RSU voisins). Ce RSU est également une passerelle vers le réseau
Internet pour les véhicules avec lesquels il et en communication.
A ces deux composants, on peut rajouter l’unité d’application (AU, Application Unit)
[SS14]. Il s’agit d’un élément intégré à l’intérieur des véhicules et permettant à l’utili-
sateur d’accéder aux applications supportées par ce véhicule : sécurité routière, diver-
tissement, etc. Ce composant est nécessairement couplé à l’OBU auquel il est relié par
une connexion filaire/sans fil. En effet, le fonctionnement des applications se base sur
les informations transportées par l’OBU, seul moyen de communication entre la voiture
et son environnement/le réseau Internet.
Considérant le fait que les réseaux véhiculaires doivent assurer la sécurité de l’en-
semble des usagers de la route, on peut ajouter à l’OBU et au RSU des éléments non
1. https://www.etsi.org/deliver/etsi_en/300600_300699/3006740201/02.01.00_30/en_
3006740201v020100v.pdf
9
propres aux réseaux véhiculaires. Les Stations de Base (BS, Base Stations), terminaux
mobiles (téléphones), panneaux de signalisation connectés, points de recharge
électriques connectés pourraient en effet s’avérer utiles pour améliorer la sécurité rou-
tière et maximiser la quantité d’informations à disposition.
Cette idée d’intégrer de nouveaux composants dans les réseaux véhiculaires pour
renforcer la sécurité routière et offrir de nouveaux services fait partie des principes de
base de l’Internet des véhicules (cf. Section 2.4.2).
2.2.3 De nombreux types de communication

Pour permettre l’établissement de communications entre les différents composants
intégrés aux réseaux véhiculaires (cf. Section 2.2.2), la normalisation de nombreux
types de communication, présentés en figure 2.1, est nécessaire 2 :
— Véhicule-à-Véhicule (V2V, Vehicle-to-Vehicle) : il s’agit de communications di-

rectes, sans fil, entre véhicules. Ces communications permettent premièrement au
véhicule à se repérer dans l’espace, en récupérant différentes informations prove-
nant des véhicules environnants (position, vitesse, distance). Ces communications
permettent également la diffusion rapide de messages de prévention : modifica-
tion de vitesse, changement de direction, détection d’obstacle, etc. Ces communi-
cations visent donc à réduire les risques d’accidents routiers. Les communications
V2V peuvent s’appuyer sur des technologies de communication courte portée spé-
cifiquement conçues pour les communications véhiculaires (cf. Section 2.3.3.1).
Elles peuvent également s’appuyer sur des communications cellulaires adaptée à
l’environnement véhiculaire (cf. Section 2.3.3.2) ;
— Véhicule-à-Infrastructure (V2I, Vehicle-to-Infrastructure) : il s’agit de communi-
cations entre un véhicule et un équipement appartenant à l’infrastructure de bord
de route : RSU, éclairage routier, panneau de signalisation, radar, arrêt de bus,
etc. Ces communications doivent premièrement permettre aux véhicules de mieux
s’adapter à leur environnement. En effet, les équipements de bord de route dis-
posent de différentes informations : travaux, changement de vitesse maximale,
etc. De plus, ces équipements agrègent les informations remontées par les véhi-
cule : densité de trafic, détection d’un obstacle, etc. Ces communications offrent
2. url : https://www.etsi.org/deliver/etsi_ts/122100_122199/122185/14.03.00_60/ts_
122185v140300p.pdf
10
également une passerelle Internet aux véhicules lorsque les RSU sont connectés
au réseau Internet. Il est à noter que les communications V2I s’appuient sur la
technologie de communication courte portée conçue pour les réseaux véhiculaires
(cf. Section 2.3.3.1) ;
— Véhicule-à-Réseau (V2N, Vehicle-to-Network) : il s’agit de communications entre
un véhicule et un équipement appartenant au réseau de communication cellulaire
(cf. Section 2.3.3.2), les BS notamment. Ces communications fournissent les fonc-
tionnalités des communications V2I dans des zones non couvertes par des équipe-
ments de bord de route (RSU). Ainsi, les BS peuvent être utilisées pour transmettre
des informations entre véhicules : état de la chaussée, accident, etc. De plus, ces
communications V2N garantissent un accès à Internet. Les véhicules peuvent donc
les utiliser pour se connecter à des services distants. On pourra alors parler de
communications Véhicule-à-Cloud (V2C, Vehicle-to-Cloud) [RVK+ 12]. Ces services
Cloud peuvent notamment correspondre à des applications de gestion globale de
sécurité routière ou de gestion du trafic routier ;
— Véhicule-à-Personne (V2P, Vehicle-to-Person) : il s’agit de communications entre
un véhicule et un usager de la route non motorisé : piéton, cycliste, etc. Ces com-
munications doivent permettre de réduire les risques de collisions entre véhicules
et usagers de la route. Pour ce faire, les communications V2P peuvent s’appuyer
sur différentes technologies (Bluetooth Low Energy, Ultra Wide Band, réseau cel-
lulaire) [AMS+ 14]. Ces communications peuvent également prendre différentes
formes. Tout d’abord, unilatérale, dans ce cas, une seule des entités est avertie de
l’arrivée de l’autre entité (usager de la route ou véhicule). Ensuite, bilatérale, dans
ce cas, les deux entités (usager de la route et véhicule) sont informées du risque
lié à l’arrivée de l’autre entité 3 ;
— Infrastructure-à-Infrastructure (I2I, Infrastructure-to-Infrastructure) : il s’agit de
communications filaires ou sans fil entre deux équipements réseau (BS, RSU).
Ces communications permettre premièrement de diffuser géographiquement des
données. Ainsi, des BS et RSU voisins peuvent échanger des informations (sécu-
rité routière, trafic, divertissement) qui seront ensuite transmises aux véhicules
(cf. Section 2.3.2.2). Ces communications peuvent également offrir une connecti-
3. U.S. Department of Transportation ; Connected Vehicles : Vehicle-to-Pedestrian Communications,
https://www.its.dot.gov/factsheets/pdf/CV_V2Pcomms.pdf
11
F IGURE 2.1 – Principaux types de communication V2X
vité Internet aux RSUs non directement connectés au réseau. Ainsi, une remontée
d’informations aux applications Cloud et un traitement plus global des données
deviennent possible.
A ces types de communication primaires on peut ajouter différents types de com-
munication aujourd’hui envisagées, les communications Véhicule-à-Réseau électrique
intelligent (V2G, Vehicle-to-Grid) et Véhicule-à-Batiment (V2B, Vehicle-to-Building)
[GZ16].
L’ensemble des types de communication véhiculaires sont rassemblées sous un pa-
radigme global : l’idée de communication Véhicule-à-Tout (V2X, Vehicle-to-Everything)
[CHS+ 17]. Les réseaux V2X doivent permettre au véhicule de communiquer avec tout
type de noeud existant dans son environnement. Ainsi, le bon fonctionnement des ser-
vices de sécurité routière et de fluidité du trafic pourrait être garanti. De plus, de nou-
velles applications commerciales, favorisant le déploiement des réseaux véhiculaires,
pourraient être conçus. La figure 2.1 offre une vision rapide des principaux types de
communication introduits dans cette section.
2.2.4 Résumé
Les réseaux de communications véhiculaires présentent des caractéristiques intrin-
sèquement liées au fait que les noeuds sont des véhicules. Il s’agit notamment de la
12
haute dynamicité de la topologie réseau, des connexions/déconnexions fréquentes, du

nombre important de noeuds, de la densité réseau variable et de l’existence de zones
d’intérêt (cf. Section 2.2.1). Ces réseaux véhiculaires sont également définis par l’utili-
sation de composants particuliers, OBU et RSU, couplés à des équipement communs :
stations de base, terminaux mobiles (cf. Section 2.2.2). Enfin, ils sont caractérisés par
différents types de communication, propres à cet environnement (V2V, V2I, V2N, V2P,
V2G) et rassemblés sous l’idée de V2X (cf. Section 2.2.3).
2.3 Un objectif : Les Systèmes de Transport Intelligents

Coopératifs
Dans cette section est présentée la raison d’être des réseaux véhiculaires : les C-
ITS (cf. Section 2.3.1). Les principales applications C-ITS (cf. Section 2.3.2.1), leurs
besoins (cf. Section 2.3.2.2) et les technologies d’accès nécessaires à leur déploiement
(cf. Section 2.3.3) sont ainsi introduits. De plus, l’architecture de communication C-ITS
standardisée (cf. Section 2.3.4) est décrite.
2.3.1 Les C-ITS, raison d’être des réseaux véhiculaires

Pour diminuer le nombre d’accidents routiers, le développement de nouvelles so-
lutions est apparu une nécessité [Weg17]. Les Systèmes de Transport Intelligents Co-
opératifs (C-ITS, Cooperative Intelligent Transportation Systems) [Fes14] sont une des
solutions envisagées. En effet, les C-ITS, visent à renforcer la sécurité routière, la flui-
dité du trafic et le confort des usagers de la route. Leur fonctionnement se base avant
tout sur un échange efficace de données entre usagers de la route, concessionnaires
autoroutiers et autorités publiques.
Or, la mise en place de ces échanges nécessite le développement de réseaux de com-
munications qui garantiront des communications fiables entre véhicules et entre véhi-
cules et infrastructure de bord de route. Par conséquent, l’avènement des réseaux de
communication véhiculaires et des C-ITS, portés par de nombreux pays (France, Alle-
magne, Japon, USA, etc.), sont intrinsèquement liés.
2.3.2 Les applications C-ITS

Cette section présente les principales applications véhiculaires (cf. Section 2.3.2.1)
et les besoins de ces applications (cf. Section 2.3.2.2).
13
2.3.2.1 Des applications nombreuses et variées
Grâce aux différents types de communication V2X, beaucoup d’applications sont

envisagées pour les réseaux véhiculaires. Les applications sont généralement classées
en trois grandes catégories de services : sécurité routière, fluidité du trafic et confort
et divertissement du passager. Néanmoins, une décomposition plus fine est possible
[MCK19a, ZCC+ 16] (cf. Tableau 2.1) :
— la sécurité routière : le but premier des systèmes C-ITS est de diminuer les risques
d’accidents de la route. Ceci peut être réalisé au travers de systèmes avertissant
le conducteur de risques extérieurs et en mettant en place des réactions automa-
tiques suite à la détection de ces risques. Ainsi, il est, par exemple, question de
détection d’obstacles sur la route, de coordination des intersections et de préven-
tion coopérative de collision ;
— la fluidité du trafic : le but premier de ces services est de gérer les déplacements
des usagers de la route et de les optimiser en fonction de différents facteurs :
pollution, durée, coût, etc. Ainsi, il est, par exemple, question de gérer le trafic en
temps réel, de réserver des places de parking ou de créer des cartes d’une manière
coopérative [EZCD14] ;
— la maintenance du véhicule : le but premier de ces services est de superviser
en temps réel l’état du véhicule afin d’optimiser les coûts de maintenance et de
simplifier son contrôle. Il s’agit par exemple de maintenance à distance (véhicules
reconfigurables, analyse des données) et d’assistant virtuel personnel pour une
prise de rendez-vous simplifiée (réservation de pièces, contrôle technique, etc.) ;
— le divertissement des passagers : le but premier de ces services est de permettre
aux usagers de la route de se divertir et de s’instruire et d’offrir de la visibilité
aux annonceurs. Il est, par exemple, question d’applications multimédia (musique,
vidéo, réseaux sociaux), de réalité augmentée ou de points d’intérêt (magasins,
promotions, etc.) ;
— l’assistance au conducteur : le but premier de ces services est de simplifier
la conduite du véhicule et de limiter les tâches assignées au conducteur. Il est,
par exemple, question d’aide à la conduite automobile (ADAS, Advanced Driver-
Assistance Systems), de conduite à distance du véhicule ou d’automatisation totale
du véhicule ;
14
— la supervision de la santé : le but premier de ces services est de s’assurer du

bien être et de la santé du conducteur et de ses passagers. Il est, par exemple,
question de détection coopérative de niveau de fatigue, de stress ou d’alcoolémie
[ASABZ13], d’adaptation de l’environnement à l’humeur des passagers ou d’assis-
tance médicale [UP13].
Type de service Exemples d’applications

Prévention coopérative de collision,
Sécurité routière Gestionnaire d’intersections,
Détection d’obstacles
Gestion en temps réel du trafic routier,
Fluidité du trafic Création coopérative de cartes HD,
Gestion de places de parking
Assistant virtuel personnel,
Maintenance du véhicule
Maintenance à distance du véhicule
Applications multimédia,
Divertissement Réalité augmentée,
Points d’intérêt
Aide à la conduite automobile (ADAS),
Assistance au conducteur
Conduite à distance du véhicule
Détection de fatigue,
Supervision de la santé Confort de l’utilisateur,
Assistance médicale
Tableau 2.1 – Principales applications des réseaux véhiculaires
2.3.2.2 Des besoins diversifiés
De part leur nombre et leur diversité (cf. Tableau 2.1), les applications véhiculaires
ont nécessairement des besoins différents. Différents travaux ont proposé une analyse
des critères de performance (KPIs, Key Performance Indicators) des différentes applica-
tions véhiculaires [CMIM17, FF17]. Les principaux critères sont :
— le débit de données : peut être défini ici comme le nombre de bits transmis
par unité de temps, il est généralement exprimé en bits par seconde. Le débit de
15
données minimal peut être calculé en fonction de deux paramètres, le nombre

maximal de messages transmis par seconde et la taille d’une unité de données ;
— la latence : peut être définie ici comme le délai induit par le réseau de communi-
cation pour la transmission de l’émetteur au récepteur d’une unité de données (pa-
quet, trame, etc.) d’une application. Cette latence peut être mesurée à différents
niveaux du modèle Open Systems Interconnection (OSI) [BBSA14]. La latence
maximale supportée pour la transmission d’un message de la couche Application
d’un émetteur à la couche Application d’un récepteur sera nommée latence de
bout-en-bout ;
— la fiabilité : peut être définie ici comme la probabilité que la valeur d’un para-
mètre donné (latence, taux d’erreur, etc.) entre la couche n d’un émetteur et la
couche n d’un récepteur soit inférieure à la valeur maximale supportée par l’appli-
cation considérée [FF17]. D’après cette définition, la fiabilité peut être mesurée à
différents niveaux du modèle OSI. Néanmoins, dans la suite de ce document, on
se concentrera sur la mesure de la fiabilité pour une transmission de bout-en-bout,
de la couche Application d’un émetteur à la couche Application d’un récepteur ;
— la zone de distribution : peut être définie ici comme l’étendue de la zone géo-
graphique dans laquelle les données produites par une application doivent être
distribuées. Une zone de distribution peut caractériser un ensemble d’applications
(cf. Tableau 2.2) ;
— le type de transmission : peut être défini ici comme le mode de transmission
utilisé pour la diffusion des données générées par une application donnée. Ce
type de transmission est ici défini par trois paramètres principaux [TOAV17]. Le
premier d’entre eux est la natures des messages : périodiques ou non. Le second
paramètre est le mode de diffusion : unicast, multicast, broadcast. Le troisième
paramètre correspond aux types de communication utilisés pour la transmission
de données : V2V, V2P, V2N, V2I, I2I (cf. Section 2.2.3).
Le tableau 2.2 présente ces indicateurs de performance pour différentes applica-

tions véhiculaires, parmi les plus courantes. Les données contenues dans ce tableau pro-
viennent des informations mises à disposition par le projet européen 5GCAR ([FF17])
et remontées par les auteurs de [CMIM17].
Du tableau 2.2, on peut tirer différents enseignements :
16
Type de Débit de Zone de Type de

Application Latence Fiabilité
service messages distribution transmission
Non Périodique
Gestionnaire Non
50ms 99% 50-100m Broadcast
d’intersections bloquant
V2V, V2P, V2N, V2I, I2I
Sécurité
Périodique
routière Détection Non
10ms 99 à 99.9% 50-100m Broadcast
d’obstacles bloquant
V2V, V2P, V2N, V2I, I2I
Prévention Périodique ou non
Non
coopérative de 10ms 99 à 99.9% > 1km Broadcast ou Unicast
bloquant
collision V2V, V2P, V2N, V2I, I2I
Création Périodique
coopérative 1Mbps 30ms 99 à 99.9% > 1km Broadcast
Fluidité
de cartes HD V2V, V2P, V2N, V2I, I2I
du
Gestion
trafic Périodique ou non
intelligente Non
100ms 99% 50-100m Broadcast ou Unicast
de l’éclairage bloquant
V2I, V2N
public
Gestion Périodique ou non
Non Non Non
de places 500m-1km Multicast ou Unicast
bloquant bloquant bloquant
de parking V2I, V2N
Périodique ou non
Conduite Non
Assistance 10Mbps 1ms 100% Broadcast ou Unicast
autonome concerné
au V2V, V2P, V2N, V2I, I2I
conducteur Périodique ou non
Conduite à Non
25Mbps 20ms 99.999% Unicast
distance concerné
V2N, V2I, V2V, V2P
Gestion Maintenance Périodique ou non
Non Non Non Non
du à Multicast ou Unicast
bloquant bloquant bloquant concerné
véhicule distance V2N, V2I
Streaming
Non Périodique
vidéo Non
10Mbps 150ms > 1km Unicast ou Multicast
(Téléchargement bloquant
Divertissement V2N, V2N, V2I
coopératif 4 )
Périodique ou non
Points Non Non Non
> 1km Broadcast ou Multicast
d’intérêt bloquant bloquant bloquant
V2I, V2N
Tableau 2.2 – Identification des besoins des principales applications V2X
— de nombreuses applications véhiculaires son caractérisées par une zone de dis-

tribution. Il s’agit des applications destinées à la sécurité routière (gestionnaire
d’intersections, détection d’obstacles, prévention coopérative de collision), la flui-
dité du trafic (création coopérative de cartes HD, gestion intelligente de l’éclairage
public, gestion de places de parking) ou au divertissement (points d’intérêt, télé-
chargement coopératif) ;
— il existe une grande diversité dans les besoins des applications. En effet, ces dif-
férences sont notables tant pour la fiabilité (non bloquant à 99%), que la latence
(non bloquant à 1ms), le débit (non bloquant à 15Mbps), l’étendue de la zone de
distribution (50m à plusieurs kilomètres) et le type de transmission (périodique
17
F IGURE 2.2 – Couche protocolaire ITS-G5
ou non, unicast/multicast/broadcast).
2.3.3 Deux technologies d’accès principales

Les types de communication V2V, V2I, V2N, voire V2P [BSN14], s’appuient sur deux
grands types de technologies d’accès. D’un côté des communications courte portée spé-
cialement définies pour les réseaux véhiculaires (cf. Section 2.3.3.1). D’un autre, les
réseaux de communication cellulaires (cf. Section 2.3.3.2). Cette section vise à présen-
ter ces technologies de communication.
Il est à noter que l’intégration de ces technologies d’accès dans l’architecture de com-
munication véhiculaire et leur interopérabilité est prévue par l’architecture de référence
C-ITS (cf. Section 2.3.4). Un tableau proposant une comparaison technique des techno-
logies présentées dans cette section est fourni en annexe (cf. Annexe B .).
2.3.3.1 ETSI ITS-G5
L’ITS-G5 [LPS+ 16] est la solution proposée par l’ETSI (European Telecommunications
Standards Institute) pour le déploiement de réseaux de communication véhiculaires per-
formants. Aujourd’hui, les réseaux cellulaires prennent de plus en plus d’ampleur dans
l’environnement véhiculaire. Toutefois, l’ITS-G5 a été la première solution à avoir été
mise en avant par les industriels et chercheurs pour les communications véhiculaires.
Cette solution, s’appuie sur les composants de base des réseaux véhiculaires, RSU et
OBU (cf. Section 2.2.2) et doit permettre de supporter des communications V2V et V2I.
L’architecture de communication de cette technologie d’accès ITS-G5 [GMS+ 18],
18
suivant le principe du modèle OSI, repose sur cinq couches principales (cf. Figure 2.2) :
— l’IEEE 802.11p : dérivé de la norme IEEE 802.11a, l’IEEE 802.11p définit les
couches Physique et Liaison du modèle OSI pour la technologie ITS-G5. Créé à
l’origine par la Commission Fédérale des Télécommunications américaine, ce stan-
dard offre des améliorations (gestion du spectre des fréquences) devant permettre
le développement de communications V2V et V2I. Pour garantir une résistance au
phénomènes d’atténuation et de brouillage du signal (fading), et à la propagation
multi trajet, l’IEEE 802.11p se base sur une bande de fréquence réduite de moitié
par rapport à l’IEEE 802.11a (10 MHz) [Kuk13]. Ce standard s’appuie également
sur deux technologies principales que sont la technique de multiplexage OFDM
(Orthogonal Frequency-Division Multiplexing), avec une évolution de l’intervalle de
garde et du rythme de transmission par rapport à l’IEEE 802.11a, et la méthode
d’accès CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) ;
— l’ITS-G5 DCC (ITS-G5 Decentralized Congestion Control) : ce contrôle de conges-

tion décentralisé (couche Accès) est déployé au sein de l’ensemble des stations
C-ITS. Ce mécanisme doit permettre de limiter la congestion du réseau. Pour ce
faire, il repose sur une allocation optimale des ressources entre les stations C-ITS
en fonction du niveau d’occupation des différents canaux de communication. Ceci
est rendu possible par une mesure précise du taux d’occupation des canaux de
communication (CBR, Channel Busy Ratio) ;
— L’ITS GeoNet et le BTP : l’idée de routage géographique (GeoNet, Geo Networ-

king) [SSCU16] a été à l’origine proposée pour les réseaux mobiles sans fils. Elle
est ensuite apparue comme une solution pertinente pour distribuer géographi-
quement les données générées par les applications C-ITS (cf. Section 2.3.2.2). Le
fonctionnement de ce protocole se base sur l’échange régulier de messages entre
véhicules (beaconing) et sur la définition de Table de Position (Location Table)
au niveau de chacun des véhicules. En utilisant ces deux mécanismes, une dis-
tribution des données, dans une zone géographique donnée, devient possible. Le
Protocole de Transport Basique (BTP, Basic Transport Protocol), similaire au proto-
cole UDP, fournit quand à lui une solution permettant de transporter le protocole
GeoNet, ainsi que les messages C-ITS provenant des couches supérieures ;
— les messages C-ITS : ces messages C-ITS correspondent à la définition de fonc-
19
tions (ou services) standardisées nécessaires au fonctionnement des applications

C-ITS. Deux grandes catégories de messages sont spécifiées pour la sécurité rou-
tière [SPMS13], les messages CAM (Cooperative Awareness Messages) et les mes-
sages DENM (Decentralized Environmental Notifications Message). Les messages
CAM doivent permettre aux véhicules de mieux s’adapter à leur environnement
grâce à un échange d’informations réguliers concernant leur statuts (position, vi-
tesse, direction) et leurs attributs (dimension, type de véhicule, etc.). Les messages
DENM doivent permettre une réaction rapide à tout évènement anormal (obstacle,
ralentissement, etc.) grâce à une diffusion efficace des informations (type d’évène-
ment, lieu, etc.) aux véhicules se situant dans la zone impactée par cet évènement.
D’autres types de messages s’ajoutent aux messages CAM/DENM, notamment les
messages IVIM (Infrastructure to Vehicle Information Message), MAPEM (MAP (to-
pology) Extended Message), STAPEM (Signal Phase And Timing Extended Message),
SREM (Signal Request Extended Message) et SSEM (Signal request Status Extended
Message ). L’ensemble de ces messages (IVIM, MAPEM, STAPEM, SREM, SSEM),
normalisés par l’ETSI 5 , sont utilisés par les applications C-ITS nécessitant une in-
teraction entre infrastructure de bord de route et véhicules : gestion de l’éclairage,
gestion des intersections, etc. ;
— les applications : elles correspondent aux applications C-ITS présentées dans la
section 2.3.2.1. L’efficacité de ces applications, destinées à la sécurité routière, à
la fluidité du trafic, ou au divertissement des usagers de la route, repose sur un
fonctionnement efficace de l’empilement protocolaire qui vient d’être présenté :
IEEE 802.11p, ITS-G5 DCC, GeoNet, BTP, CAMs/DENMs.
2.3.3.2 Réseaux cellulaires
Les réseaux cellulaires sont l’autre approche considérée pour le déploiement des ré-
seaux de communication véhiculaires. Ces réseaux cellulaires présentent un avantage
important par rapport aux réseaux ITS-G5 : un déploiement existant à large échelle
garantissant une bonne couverture. Ils sont également en mesure d’offrir un débit de
données et une latence convenables. Deux générations de réseaux de communications
cellulaires pourraient permettre le déploiement de communications véhiculaires perfor-
5. https://www.etsi.org/deliver/etsi_ts/103300_103399/103301/01.01.01_60/ts_
103301v010101p.pdf
20
mantes : les réseaux 4G (LTE-V2X) et les réseaux 5G. Ces deux générations de réseaux
cellulaires sont rapidement introduites dans cette section.
2.3.3.2.1 LTE-V2X L’idée d’intégrer les communications véhiculaires aux réseaux

cellulaires [WMG17] a été proposée pour la premier fois en 2015 dans la Release 14 6
publiée par le 3GPP (3rd Generation Partnership Project), l’organisme à l’origine de la
spécification des réseaux cellulaires 3G et 4G. Différentes appellations sont utilisées
pour nommer ces réseaux cellulaires destinés aux communications véhiculaires : LTE-V,
LTE-V2X ou encore Cellular-V2X (C-V2X). Cette intégration des communications véhicu-
laires, nécessitant une utilisation optimale des canaux de communication et une fiabilité
élevée, repose sur deux idées majeures :
— une nouvelle interface radio : les communications cellulaires s’appuient généra-

lement sur l’utilisation d’une seule interface radio, l’interface LTE-Uu. Cette inter-
face permet à un terminal mobile (véhicule, portable) d’établir une communica-
tion avec une station de base. Aussi, pour permettre d’établir des communications
directes entre véhicules, il a été nécessaire de définir une nouvelle interface : l’in-
terface PC5. Cette interface présente différentes améliorations garantissant son
fonctionnement dans l’environnement véhiculaire : réduction de la latence, amé-
lioration du passage à l’échelle et prise en compte d’une mobilité élevée. Il est
à noter que pour cette interface PC5, on parle de lien secondaire (sidelink) par
opposition aux communications premières entre véhicules et stations de base ;
— une technologie de communication Objet-à-Object : les communications cellu-

laires reposent en temps normal sur des communications entre véhicules et sta-
tions de base (V2N). Or, les réseaux véhiculaires nécessitent des communications
directes entre véhicules (V2V) pour pouvoir garantir une faible latence et une
sécurité routière élevée. Pour offrir ces communications V2V dans l’environne-
ment cellulaire, le 3GPP a considéré l’utilisation d’une technologie existante : Prose
[TSAEA14]. Avec cette technologie, les réseaux cellulaires LTE pourraient suppor-
ter l’établissement de communications directes Objet-à-Objet de courte portée. En
effet, grâce à l’utilisation de nouveaux canaux de communication (interface PC5),
6. 3GPP, "TR 22.885 : study on LTE support for vehicle to everything (V2X) services”, Tech.
Rep., 2015., https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.
aspx?specificationId=2898
21
F IGURE 2.3 – Nouveaux modes de communication introduits pour les réseaux LTE-V2X
Prose pourrait permettre aux véhicules de découvrir et d’établir une communica-

tion directe avec leurs voisins, sans passer par la station de base.
Ainsi, grâce à cette interface (PC5) et cette technologie (Prose), les réseaux cellu-
laires pourraient supporter l’ensemble des applications C-ITS (cf. Tableau 2.2). En effet,
avec cette évolution, les réseaux cellulaires deviennent en capacité de supporter des
communications V2V et V2N (cf. Figure 2.3). Les communication V2N pourraient être
utilisées pour les applications C-ITS nécessitant une transmission de données dans un
zone géographique étendue (de l’ordre du kilomètre) : prévention coopérative de col-
lision, création coopérative de carte, etc. Les communications V2V pourraient quand à
elles garantir une transmission rapide de données dans des zones géographiques peu
étendues : gestionnaire d’intersections, détection d’obstacles, etc.
Il est à noter que les communications cellulaires (V2N) reposent habituellement
sur deux modes de communication : liaison montante (uplink) et liaison descendante
(downlink). Or, ces modes de communication ne sont pas adaptés à des communications
directes entre véhicules (V2V). Aussi, deux nouveaux modes de communication ont été
introduits pour les communication V2V : le mode en couverture (in-coverage, mode 3) et
le mode hors couverture (out-of-coverage, mode 4). Ces deux modes de communication
correspondent à deux cas possibles. Dans le premier cas, en couverture, on considère
que les deux véhicules sont directement connectés à une station de base. La station de
base détermine alors quelles sont les ressources en communication (canal) qui doivent
22
être utilisées pour cette communication V2V. On parle de communication assistée par
le réseau. Dans le second cas, hors couverture, on considère qu’un de ces véhicules, ou
ces deux véhicules, sont hors de la zone de couverture des stations de base. Les véhi-
cules déterminent alors par eux-mêmes quelles ressources en communication doivent
être utilisées pour cette communication V2V. La figure 2.3 offre une vue d’ensemble des
différentes interfaces et des différents modes de communication existants dans l’envi-
ronnement LTE-V2X.
2.3.3.2.2 5G NR La 5G New Radio (5G NR) [DPS18], est une nouvelle technologie
d’accès radio développée par le 3GPP. Elle doit servir de base aux réseaux cellulaires
de 5eme génération. Ces réseaux cellulaires de 5eme génération devraient supporter trois
grands types de communication [PTSD18] :
— des communications mobiles haut débit (eMMB, enhanced Mobile BroadBand) :

devant permettre la gestion d’applications multimédia nécessitant des débit de
données très élevés ;
— des communications à haute fiabilité et faible latence (URLLC, Ultra-Reliable
and Low-Latency Communications) : devant permettre la gestion de communica-
tions aux contraintes importantes en latence, fiabilité et disponibilité. L’URLLC est
notamment destiné aux applications véhiculaires (sécurité routière) ;
— des communications machine-à-machine massives (MMTC, Massive Machine-
Type Communication) : devant permettre la gestion d’un nombre important (le
passage à l’échelle) de communications directes entre machines, notamment pour
l’Internet des Objets [LHLS17].
Pour assurer ces services, la technologie d’accès radio 5G NR nécessite différentes

améliorations par rapport aux technologies existantes : gestion du spectre de fré-
quences, latence, passage à l’échelle, fiabilité. Pour ce faire, l’intégration de différentes
techniques est considérée. On parle notamment de full duplex en bande de fréquences
[KLH15], d’ondes millimétriques (mmWave) [RSM+ 13], d’accès multiple non orthogo-
nal (NOMA, Non-Orthogonal Multiple Access) [SKB+ 13] et d’entrées-multiples sorties-
multiples massives (massive MIMO, massive Multiple-Input, Multiple-Output) [LETM14].
Avec ces évolutions, la technologie 5G NR pourrait, tout comme la technologie LTE-
V2X, supporter des communications véhiculaires, tout en garantissant des performances
23
bien supérieures (débit, latence). Aussi, ce standard, dont le déploiement à grande

échelle devrait survenir dans les années à venir, apparaît aujourd’hui comme l’avenir
des réseaux de communication cellulaire et des réseaux de communication véhiculaires.
Il est à noter que deux modes de déploiement sont considérés pour le déploiement de
la technologie 5G NR : le mode non-autonome (non standalone) et le mode autonome
(standalone) [GPR+ 19]. Le mode non-autonome correspond à un cas où la technolo-
gie 5G NR s’appuie sur l’infrastructure de communication LTE pour le contrôle de la
signalisation. La technologie 5G NR se concentre alors uniquement sur le transfert d’in-
formations (débit plus élevé). Le mode autonome correspond, quant à lui, à un cas où
la technologie 5G NR s’appuie sur une infrastructure et un coeur de réseau 5G. La tech-
nologie 5G NR gère alors le transfert d’informations et le contrôle de la signalisation.
On peut également noter que les réseaux de 5eme génération sont pensés pour
permettre l’utilisation simultanée de plusieurs technologies d’accès radio (multi-RAT,
multiple-Radio Access Technologies) pour un même terminal mobile. Il deviendrait alors
possible pour un véhicule de réceptionner des données provenant d’autres véhicules (in-
terface LTE PC5) tout en transmettant, dans un même temps, des données à une station
de base ou à d’autres véhicules (interface 5G NR). Cette approche offre d’importantes
perspectives en terme de capacité et de débit pour les réseaux cellulaires et véhiculaires.
2.3.4 Une architecture C-ITS standardisée

Les travaux conjoints de différents organismes de standardisation, l’ARIB (Associa-
tion for Radio Industry and Business), l’ETSI (European Telecommunications Standards
Institute), l’IEEE (Institute of Electrical and Electronics Engineers) et l’ISO (Internatio-
nal Organization for Standardization) ont résulté en la définition d’une architecture de
communication C-ITS standardisée 7 .
L’architecture visible en figure 2.4 correspond à la Release de l’architecture de réfé-
rence spécifiée dans l’ETSI 302 665 et l’ISO 27217. Cette architecture avait initialement
été conçue pour permettre un déploiement efficace de communications directes entre
véhicules (cf. Section 2.3.3.1). Toutefois, elle s’est aujourd’hui ouverte à d’autres tech-
nologies de communication afin de répondre aux besoins de l’ensemble des applications
C-ITS identifiées (cf. Section 2.3.2.2).
7. ETSI EN 302 665 V1.1.1, url : https://www.etsi.org/deliver/etsi_en/302600_302699/

302665/01.01.01_60/en_302665v010101p.pdf
24
F IGURE 2.4 – Architecture de référence C-ITS
Cette architecture est composée de trois plans principaux :

— le plan de gestion (MP, Management Plane) : comme spécifié dans la documenta-
tion de l’ETSI (7), ce plan doit permettre une gestion globale de l’architecture de
communication C-ITS. Parmi les fonctionnalités du MP, on peut citer la sélection
en temps réel de la technologie d’accès devant être utilisée pour une application
donnée, la prioritisation des communications en fonction de l’importance des ap-
plications et la gestion du contrôle de congestion (2.3.3.1). On peut également
évoquer l’accès à la base d’information pour la gestion du réseau (MIB, Manage-
ment Information Base) permettant de gérer les échanges inter-couches du plan de
contrôle et de données ;
— le plan de de données et de contrôle (CDP, Control and Data Plane) : ce plan
est également parfois nommé "plan protocolaire de communication". Il décrit les
fonctionnalités nécessaires à l’établissement de communications entre les diffé-
rents terminaux C-ITS (RSU, OBU, BS, etc.) et à la gestion des données produites
25
par ces communications. Il est composé de trois couches principales. La première

d’entre elle est la couche Access qui offre aux applications C-ITS une communi-
cation transparente via différentes technologies d’accès radio (ITS-G5, LTE-V2X,
5G NR, Li-Fi, LPWAN, Ethernet LAN). Cette couche établit également une liaison
(LLC, Logical Link Control) entre ces technologies d’accès et les protocoles réseau.
La seconde couche, Networking and Transport, fournit l’ensemble des protocoles
de transport et de réseau nécessaires à l’établissement des communications entre
les stations C-ITS. Parmi ces protocoles on retrouve des solutions classiques (TCP,
UDP), pour certaines adaptées à un environnement mobile (IPV4 et IPV6 NEtwork
MObility [LJP03]). On retrouve également des protocoles propres à l’environne-
ment véhiculaires tels que GeoNet et BTP (cf. Section 2.3.3.1). Enfin, la troisième
couche, Facilities, correspond aux services nécessaires au fonctionnement des dif-
férentes applications C-ITS (traitement et affichage des données, synchronisation
des communications, support de cartes interactives, etc.) ;
— le plan de sécurité et de respect de la vie privée (SPP, Security and Privacy
Plane) : ce plan contient les fonctionnalités nécessaires à la sécurisation des appli-
cations C-ITS, équipements C-ITS et protocoles de communication C-ITS. Il assure
également la protection de la vie privée des usagers de la route (traçage d’itiné-
raire par exemple). Parmi les fonctionnalités de ce plan, on peut citer : la mise
en place de pare-feux et de mécanismes de gestion d’intrusions, la gestion des
identités et la mise en place de mécanismes garantissant l’anonymat (ou pseudo-
anonymat) et la définition de modules devant garantir la sécurité physique des
équipements (HSM, Hardware Security Module).
Le fonctionnement des applications C-ITS (sécurité routière, fluidité du trafic, di-
vertissement, etc.), présentées comme une couche horizontale dans l’architecture de
référence (cf. Figure 2.4), repose sur l’interaction entre ces trois plans : plan de gestion
(MP), plan de données et de contrôle (CDP) et plan de sécurité et de respect de la vie
privée (SPP).
2.3.5 Résumé
Les C-ITS sont la raison d’être principale des réseaux véhiculaires (cf. Section 2.3.1).
Pensés à l’origine pour améliorer la sécurité routière, le panel d’applications supportées
par les C-ITS est aujourd’hui bien plus large (cf. Section 2.3.2.1) : sécurité routière,
26
fluidité du trafic, maintenance du véhicule, etc. Pour supporter ces applications aux
besoins variés (cf. Section 2.3.2.2), différentes technologies de communication (ITS-
G5, LTE-V2X) ont été considérées (cf. Section 2.3.3). Celles ci ont été intégrées dans une
architecture de référence proposée par l’ARIB, l’ETSI, l’IEEE et l’ISO. Cette architecture
est composée de trois plans principaux : le plan de gestion (MP), le plan de données et
de contrôle (CDP) et le plan de sécurité et de respect de la vie privée (SPP) (cf. Section
2.3.4).
2.4 Une évolution nécessaire du paradigme de commu-

nication
Pour répondre aux besoins des applications C-ITS (cf. Section 2.3.2.2), les réseaux
véhiculaires ont dû évoluer. Cette évolution des réseaux véhiculaires d’une approche ad
hoc (cf. Section 2.4.1) vers l’Internet des Véhicules (cf. Section 2.4.2) est présentée dans
cette section. Le tableau 2.3 présente un récapitulatif des principales différences entre
ces deux approches.
2.4.1 L’approche d’origine, les réseaux véhiculaires ad hoc

Dans cette section, la première solution considérée pour le déploiement des applica-
tions C-ITS est présentée : l’approche VANet.
2.4.1.1 Le principe des réseaux véhiculaires ad hoc
Les réseaux véhiculaires ad hoc s’appuient sur des communications V2V et V2I (cf.
Section 2.3.3), deux composants que sont l’OBU et le RSU (cf. Section 2.2.2) et une
technologie de communication conçue pour les réseau véhiculaires : l’ITS-G5 (cf. Sec-
tion 2.3.3.1).
Ces réseaux véhiculaires ad hoc, décentralisés, se basent principalement sur des com-
munications directes entre véhicules. Ces communications garantissent de faible délais
de transmission et permettent donc de distribuer rapidement des informations concer-
nant la détection d’un obstacle, l’état de la chaussée ou un freinage d’urgence. De plus,
l’utilisation de RSUs, positionnés à des endroits stratégiques (intersections, parking)
pourrait permettre une diffusion d’informations dans des zones géographiques plus
27
Caractéristique VANET IoV

Types de OBU, RSU, BS,
OBU, RSU
composants terminaux mobiles
V2V, V2N,
Types de
V2V, V2I V2P, V2I,
communications
V2D
IEEE 802.11p
Technologies de
IEEE 802.11p LTE-V2X, 5G NR
communication
LPWAN, Li-Fi, etc.
Type d’
Plate Hiérarchique
architecture
Connectivité
Limitée Elevée
Internet
Sécurité routière Sécurité routière
(totale) (totale)
Applications Fluidité du trafic Fluidité du trafic
supportées (partielle) (totale)
Divertissement Divertissement
(partielle) (totale)
Tableau 2.3 – Architectures VANet et IoV : Comparaison
étendues et une supervision plus efficace du trafic routier. Ainsi, les réseaux véhicu-
laires ad hoc améliorent la sécurité routière et la fluidité du trafic.
Toutefois, considérant les besoins des applications C-ITS, différentes limites peuvent
être identifiées pour cette approche. Celles-ci sont présentées dans la section suivante
(cf. Section 2.4.1.2).
2.4.1.2 Les limites des réseaux véhiculaires ad hoc
Les réseaux VANet présentent certaines limitations qui pourraient nuire au dévelop-
pement de services C-ITS globaux et efficaces. Parmi les principales limites identifiées
[KAC+ 16], on peut citer :
— le manque d’interopérabilité : l’architecture VANet s’appuie uniquement sur des

communications courte portée entre véhicules et RSU. Elle ne permet donc pas
l’utilisation et l’interconnexion de différents réseaux de communication : ITS-G5,
28
F IGURE 2.5 – Des VANet à l’IoV
LTE-V2X, Li-Fi, etc. Ceci complexifie le déploiement de services de transport intel-

ligents globaux et fiables ;
— le faible nombre de types de communication supportés : les réseaux VANet,

s’appuient uniquement sur des communications V2V et V2I. Ils ne permettent donc
pas l’intégration de nouveaux types d’objets connectés : caméras, téléphones, etc.
Ceci pourrait limiter l’efficacité de différentes applications telles que la détection
de piétons ou la création coopérative de carte ;
— la connectivité Internet limitée : l’architecture VANet ne garantit pas une connec-

tivité Internet aux usagers de la route. En effet, de part le faible nombre de RSU
déployés, peu de véhicules pourraient bénéficier d’une connectivité Internet. Par
conséquent, le développement de services commerciaux, qui pourraient attirer de
nouveaux investisseurs (publicité, divertissement, etc.), et de services globaux de
gestion du trafic est impossible ;
— le traitement complexe des données : la faible connectivité Internet et les capa-

cités de calcul et de stockage limitées, rendent impossible le traitement de volumes
29
de données importants avec l’approche VANet. Ainsi, la prise de décisions globales

et "intelligentes" est complexe.
Les réseaux VANet ne représentent donc pas une solution permettant le déploiement
de l’ensemble des applications C-ITS (cf. Section 2.3.2.1). Aussi, pour répondre aux be-
soins de ces applications C-ITS, améliorer la sécurité routière, garantir une connectivité
Internet et offrir de nouvelles opportunités aux investisseurs (fournisseurs de services,
constructeurs automobiles, etc.), le développement d’une nouvelle architecture de com-
munication est nécessaire. Cette architecture de communication, appelée Internet des
Véhicules (IoV), est présentée dans la section suivante (cf. Section 2.4.2).
On peut noter que dans le chapitre suivant nous nous pencherons plus en détail sur
les limites techniques (flexibilité, sécurité, passage à l’échelle, intelligence) des réseaux
véhiculaires (cf. Section 3.2.1).
2.4.2 Le présent et l’avenir : l’Internet des Véhicules

Comme cela a été montré dans la section précédente (cf. Section 2.4.1.2), l’archi-
tecture de communication des réseaux VANet présente certaines limites empêchant le
déploiement de l’ensemble des applications C-ITS.
C’est pourquoi un nouveau paradigme de communication, s’inspirant de l’Internet
des Objets, a été défini : l’Internet des Véhicules (IoV). Pour surmonter les limitations
des réseaux VANet, l’Internet des Véhicules s’appuie sur trois grands principes :
— l’intégration de différentes technologies de communication : les communica-

tions ITS-G5 représentent un moyen de communication intéressant pour les ap-
plications liées à la sécurité routière et la fluidité du trafic (latence, fiabilité).
Néanmoins, l’ITS-G5, offre une connectivité Internet limitée. Cette technologie ne
permet donc pas le déploiement de services liés au divertissement et ne garantit
pas un traitement optimal des données pour les applications de sécurité routière
et de fluidité du trafic. C’est pourquoi, l’Internet des Véhicules propose de consi-
dérer différentes technologies d’accès ITS-G5, LTE-V2X, Li-FI etc. Ainsi, un accès
Internet continu pourrait être garanti ;
— l’intégration des réseaux véhiculaires dans l’Internet des Objets : l’Internet

des Objets ([A+ 09]) doit permettre des communications en temps réel, en tout
instant, entre tout type d’objets. L’établissement de connexions entre véhicules et
30
objets (route connectée, caméra de surveillance, montre connectée, etc.) pourrait

permettre d’élargir le champs des applications C-ITS. Aussi, l’Internet des Véhi-
cules propose d’intégrer les réseaux véhiculaires à l’Internet des Objets et à aux
Ville Intelligente (Smart City, [SLF11]) ;
— un traitement optimal des données : le développement d’applications C-ITS tou-

jours plus efficaces repose sur un traitement des données optimal. La garantie
d’une connectivité Internet permanente rend possible une remontée d’informa-
tions vers des serveurs Cloud externalisés et une analyse de volumes de données
importants par ces serveurs. Ceci pourrait permettre de garantir une fluidité du
trafic et une sécurité routière maximale. Ainsi, l’Internet des Véhicules propose
d’intégrer des solutions de traitement de données performantes et "intelligentes",
telles que des techniques d’Intelligence Artificielle.
En s’intégrant à l’Internet des Objets, en prenant en compte différentes technologies

de communication et en proposant un traitement de données efficace, l’Internet des Vé-
hicules semble représenter l’avenir des réseaux véhiculaires (cf. Tableau 2.3). En effet,
cette approche permet d’améliorer de fonctionnement des applications existantes (sécu-
rité routière, fluidité du trafic) et de développer de nouveaux services (maintenance du
véhicule, santé, divertissement). De plus, l’Internet des Véhicules s’ouvre à de nouveaux
acteurs (fournisseurs de service, opérateurs) qui participeront au développement des
réseaux véhiculaires.
Il est à noter que les communications entre objets (Internet des Objets) et véhicules
pourraient reposer sur des technologies de communication et des types de communi-
cations (V2P, V2I, V2N) déjà utilisées dans les réseaux véhiculaires. D’autres techno-
logies de communication, propres à l’Internet des Objets, pourraient également être
considérées, notamment les réseaux à longue portée et basse consommation (LPWAN
Low-Power Wide-Area Network) [CMJ+ 18, SSIRR+ 19]. Dans ce cas, un nouveau type de
communication pourrait être considéré (cf. Tableau 2.3), les communications Véhicules-
à-Objet (V2D, Vehicle-to-Device). Pour offrir des communications V2V, V2I et V2N, une
autre technologie de communication, basée sur l’utilisation de la lumière visible (cf.
Tableau 2.3), pourrait être intégrée aux réseaux véhiculaires : le Li-Fi (Light-Fidelity)
[AKM17, SAA+ 15].
31
2.4.3 Résumé
Les réseaux véhiculaires ad hoc ont été la première approche proposée pour la dé-
finition de communication véhiculaires (cf. Section 2.4.1). Cette approche, basée sur
la technologie ITS-G5, permet de garantir des performances élevées pour certaines ap-
plications C-ITS nécessitant une faible latence et une fiabilité élevée. Néanmoins, cette
approche présente également certaines limites empêchant le déploiement de l’ensemble
des applications C-ITS (cf. Section 2.4.1.2). Afin de palier ces limitations, un nouveau
paradigme de communication a été introduit, l’Internet des Véhicules. Reposant sur trois
grands principes (intégration de technologies d’accès, traitement des données, intégra-
tion dans l’Internet des Véhicules), l’IoV représente l’avenir des réseaux véhiculaires. En
effet, avec l’IoV le déploiement de l’ensemble des applications C-ITS et le développe-
ment d’applications véhiculaires commerciales sont envisageables.
2.5 Conclusion
Dans ce chapitre, nous avons proposé une vision d’ensemble de l’environnement
véhiculaire.
Pour ce faire, nous avons commencé par présenter les principales caractéristiques,
les principaux types de communications et les principaux composants définissant les
réseaux véhiculaires (cf. Section 2.2).
Dans un second temps, nous nous sommes focalisés sur le principal moteur des ré-
seaux véhiculaires (cf. Section 2.3.1), les Systèmes de Transport Intelligents Coopératifs
(C-ITS). Ainsi, nous avons présenté les principales applications (cf. Section 2.3.2.2) et
technologies de communication associées à ces systèmes (cf. Section 2.3.3). Nous avons
également introduit l’architecture de référence des C-ITS (cf. Section 2.3.4) sur laquelle
nous reviendrons dans le chapitre suivant.
Enfin, nous avons justifié l’évolution des réseaux véhiculaires d’une approche ad hoc
vers une approche centralisée, l’Internet des Véhicules (cf. Section 2.4).
Considérant que l’IoV représente l’avenir des réseaux véhiculaires, dans le chapitre
suivant, nous identifierons les limites actuelles de l’IoV et introduirons notre première
contribution. Il s’agit d’une évolution de l’architecture de référence C-ITS devant per-
mettre l’avènement de l’IoV.
32
Chapitre 3
Une nouvelle architecture de

communication pour l’Internet des
Véhicules
3.1 Introduction
Dans le chapitre précédent (cf. Chapitre 3), nous avons introduit la principale rai-
son d’être des réseaux de communication véhiculaires : les Systèmes de Transport In-
telligents Coopératifs (cf. Section 2.3). Ces C-ITS, s’appuient sur une architecture de
communication de référence (cf. Section 2.3.4) et offrent un ensemble d’applications
véhiculaires (cf. Section 2.3.2.1) : sécurité routière, fluidité du trafic, etc. Pour répondre
aux besoins de ces applications (cf. Section 2.3.2.2), l’architecture de communication
véhiculaire a dû évoluer d’une approche ad hoc, VANet, (cf. Section 2.4.1), vers une
architecture centralisée, l’IoV (cf. Section 2.4.1.2).
L’IoV se base sur trois grands principes : l’intégration de nouvelles technologies de
communication, l’intégration des réseaux véhiculaires dans l’Internet des Objets et un
traitement optimal des données (cf. Section 2.4.2). Grâce à ces améliorations, les ré-
seaux véhiculaires pourraient supporter l’ensemble des applications C-ITS. De plus, de
nouveaux acteurs (fournisseurs de services, opérateurs, fabricants automobiles, etc.)
pourraient s’intéresser aux réseaux véhiculaires, attirés par les applications commer-
ciales (divertissement, publicité) envisageables avec l’IoV.
Toutefois l’avènement de l’IoV nécessite une évolution de l’architecture de commu-
nication véhiculaire. En effet, l’architecture de communication de référence (cf. Section
2.3.4), présente différentes limites qui pourraient rendre impossible le déploiement des
applications C-ITS. Il s’agit notamment du manque de fiabilité des communications, du
faible niveau de sécurisation des données et d’une gestion complexe des ressources et
des équipements terminaux [KAC+ 16].
33
3. Une nouvelle architecture de communication pour l’Internet des Véhicules
C’est pourquoi, dans ce chapitre, nous introduisons notre première contribution :

une architecture de communication pour l’IoV performante (traitement, transmission
des données) et sécurisée, évolution de l’architecture de référence C-ITS. Pour ce faire,
nous commençons par identifier les limites actuelles de l’IoV (cf. Section 3.2.1). Dans
un second temps, nous présentons les travaux existants proposant des évolutions de
l’architecture de référence C-ITS (cf. Section 3.4). Ces travaux, se basent sur différentes
solutions technologiques (réseaux définis logiciellement, virtualisation des fonctions ré-
seaux, etc.) également décrites dans ce chapitre (cf. Section 3.3). Enfin, considérant les
limites de l’architecture de référence et des travaux existants (cf. Section 3.4.4), nous
définissons une nouvelle architecture de communication pour l’IoV (cf. Section 3.5).
Notre solution s’appuie sur trois grands piliers : la définition d’un plan de connaissance,
l’évolution du plan de contrôle et de données et l’amélioration du plan de sécurité et de
respect de la vie privée définis dans l’architecture de référence.
3.2 Motivations
3.2.1 Présentation
L’IoV doit permettre de répondre répondre aux besoins des applications C-ITS (cf.
Section 2.3.2.2). Pour ce faire, l’IoV se base sur trois grands principes : l’intégration de
nouvelles technologies de communication, l’intégration des réseaux véhiculaires dans
l’Internet des Objets et un traitement plus efficace des données.
Toutefois, ces différentes évolutions n’apportent qu’une réponse partielle aux limites
actuelles des réseaux véhiculaires (cf. Section 2.4.1.2) [KAC+ 16]. En effet, différents
points doivent encore être considérés pour que l’architecture de communication de ré-
férence (cf. Section 2.3.4) puisse supporter l’ensemble des applications C-ITS. Ces amé-
liorations nécessaires peuvent être classés en différentes catégories, correspondant aux
différents plans de l’architecture de référence C-ITS :
— Contrôle et données : les avancées permises par l’IoV concernent principalement

le plan de contrôle et de données de l’architecture de référence C-ITS. En effet,
l’intégration de différentes technologies de communication et l’intégration dans
l’Internet des véhicules sont proposées pour garantir une meilleur connectivité
Internet et des échanges plus efficaces. Néanmoins, trois défis principaux peuvent
être identifiés pour ce plan [JCL19] :
34
• la reconfiguration rapide du réseau : la reconfiguration rapide de la topo-

logie du réseau véhiculaire reste un enjeu majeur. En effet, pour permettre
un routage et une distribution efficaces des données, il est essentiel que la
mobilité des véhicules et les liens de communication existants entre ces véhi-
cules puissent être rapidement pris en compte. Aussi, les réseaux véhiculaires
doivent garantir une grande adaptabilité. Or, dans un environnement où les
prises de décision (décentralisées) sont basées sur une connaissance partielle
de l’état du réseau, développer une solution flexible et fiable est complexe ;
• la gestion optimale des ressources : dans l’environnement véhiculaire la

gestion des ressources constitue également un enjeu majeur. En effet, les res-
sources en communication à disposition sont limitées. Il est donc essentiel
qu’elles soient gérées de façon efficace. Aussi, de nombreux travaux s’inté-
ressent à une gestion optimale de la bande de fréquence, de la puissance et
des canaux de communication pour limiter le nombre d’interférences. Néan-
moins, dans un environnement décentralisé, garantir une prise de décision
optimale, limitant au minimum les interférences est complexe ;
• l’interopérabilité de réseaux hétérogènes : l’intégration de réseaux d’accès

hétérogènes (5G NR, LTE V2X, ITS-G5) est permise par l’IoV. Cette intégra-
tion doit garantir une connectivité Internet importante aux véhicules. Tou-
tefois, l’interopérabilité de ces différentes technologies constitue un enjeu
majeur. En effet, coordonner efficacement ces technologies, aux protocoles et
infrastructures indépendants, est nécessaire pour garantir de bonnes perfor-
mances. Or, sans prise de décision globale ceci est complexe ;
— Gestion : l’IoV ne permet pas d’amélioration notable du plan de gestion de l’archi-

tecture de référence C-ITS. Or, ce plan est responsable de la gestion des interfaces
physiques et des applications (déploiement/mise à jour). Ainsi, il est nécessaire-
ment impacté par l’intégration de nouvelles technologies de communication, de
nouveaux services et de nouveaux objets. Pour garantir un niveau de performance
élevé pour ce plan, trois grands points semblent devoir être considérés :
• un support de différentes plateformes : les réseaux véhiculaires corres-

pondent à un nombre important d’interfaces physiques et de composants (cf.
Section 2.2.2). Ce nombre devrait encore augmenter en considérant l’inté-
35
gration des réseaux véhiculaires dans l’Internet des Objets. Aussi, les appli-
cations C-ITS, pour être efficaces, doivent pouvoir être déployées dans des
environnements aux caractéristiques différentes : architecture, système d’ex-
ploitation, etc. En considérant l’architecture matérielle actuelle, de tels dé-
ploiements pourraient être complexes ;
• une accélération du cycle de vie des applications : pour attirer de nou-

veaux investisseurs (fournisseurs de services, opérateurs), et favoriser le dé-
veloppement des réseaux véhiculaires, il est nécessaire que les nouveaux ser-
vices C-ITS/commerciaux puissent être déployés rapidement. De même, les
mises à jour (nouvelles fonctionnalités, failles de sécurité, etc.) de services
existants doivent pouvoir être réalisées de façon efficace. Or, l’architecture
matérielle actuelle, rend complexe la mise en place de déploiements rapides,
dynamiques et à la demande ;
• un déploiement flexible : les réseaux véhiculaires sont caractérisés par une

densité très variable. Ainsi, en fonction du moment et des conditions, les
ressources (interface physique, CPU, bande passante, etc.) nécessaires au
bon fonctionnement des applications peuvent varier de façon importante.
Aussi, le plan de gestion doit garantir une allocation efficace et flexible de
ces ressources. Sans cela, ce plan ne pourra être en mesure de répondre en
temps réel aux besoins des différentes applications déployées. Or, ceci pour-
rait s’avérer complexe dans l’architecture actuelle ;
— Sécurité et respect de la vie privée : l’IoV ne propose aucune amélioration di-

recte du plan de sécurité C-ITS. Or, différentes améliorations sont nécessaires pour
ce plan. En effet, certains besoins sont communs à l’ensemble des services (dispo-
nibilité, confidentialité, authentification, intégrité, non répudiation, respect de la
vie privée) offerts par le plan de sécurité et de respect de la vie privée [SL19] :
• une sécurité accrue : les projets pilotes pour le déploiement des applications
C-ITS se basent sur un système de sécurité centralisé (Infrastructure à Clé
Publique). Or, ce système centralisé constitue un point d’attaque unique. Un
attaquant qui parviendrait à prendre le contrôle de ce point central pourrait
prendre le contrôle de l’ensemble du réseau de communication véhiculaire.
Ainsi, concevoir une solution permettant d’éliminer ce point d’attaque majeur
36
est primordial ;
• le passage à l’échelle : avec le développement des réseaux véhicu-

laires, le nombre de véhicules connectés pourrait augmenter. Aussi, le
plan de sécurité et vie privé doit permettre la sécurisation et l’anonymi-
sation d’un nombre important de véhicules, se déplaçant à grande vitesse
(connexions/déconnexions fréquentes). Or, l’architecture actuelle, centrali-
sée, ne permet qu’un passage à l’échelle limité [CHC16]. Ainsi, cette approche
pourrait s’avérer inefficace pour sécuriser les réseaux véhiculaires à l’avenir ;
• l’établissement de confiance : l’établissement de confiance constitue un en-

jeu majeur dans les réseaux véhiculaires. En effet, l’IoV supporte un nombre
important d’objet connectés et de réseaux de communication. Sans confiance
entre ces objets (et entre objets et infrastructure de bord de route), la sécu-
risation des communications, et la fiabilité des informations transmises, ne
pourraient être assurés. Or, le plan de sécurité et de respect de la vie privée
de référence n’intègre pas de services basés sur la confiance ;
— Global : Au delà de ces différentes améliorations, propres à chacun des plans

de l’architecture de communication, un besoin est essentiel pour l’architecture de
communication dans sa globalité : un traitement efficace des données. En effet,
l’efficacité des services offerts par les différents plans est intrinsèquement liée aux
traitements de données qu’ils sont en mesure de réaliser. Ceci est vrai tant pour la
transmission des données (routage, contrôle de congestion, etc.), que la gestion
des applications et des interfaces (déploiement optimal, mises à jour, etc.) ou la
sécurisation des transmissions (détection d’intrusions, déni de service, etc.). Cette
idée de traitement efficace des données, objectif de l’IoV (2.4.2), doit donc être
intégrée à l’architecture de référence C-ITS.
Ainsi, pour que l’IoV puisse permettre le déploiement de l’ensemble des applications
C-ITS, de nombreuses améliorations de l’architecture de référence doivent être consi-
dérées. Certaines des ces améliorations concernent le plan de contrôle et de données
(interopérabilité, reconfiguration du réseau, etc.), le plan de gestion (flexibilité, sup-
port de différentes plateformes, etc.) ou le plan de sécurité et de respect de la vie privée
(passage à l’échelle, coût, etc.). D’autres concernent l’architecture dans sa globalité,
notamment le traitement efficace des données.
37
Face à ces besoins d’évolution, de nombreuses améliorations de l’architecture de ré-

férence C-ITS ont déjà été proposés dans la littérature (cf. Section 3.4). Ces travaux se
basent généralement sur l’utilisation de solutions technologiques innovantes (cf. Section
3.3) : réseaux définis logiciellement, virtualisation des fonctions réseau, etc. Toutefois,
certaines limites de l’architecture de référence C-ITS et certaines solutions technolo-
giques n’ont pas été considérées jusqu’ici (cf. Section 3.4.4). C’est pourquoi, dans ce
chapitre, nous introduisons également notre première contribution (cf. Section 3.5). Il
s’agit d’une évolution de l’architecture de référence C-ITS bâtie sur trois piliers majeurs.
Tout d’abord, la définition d’un nouveau plan, nommé plan de connaissance. Ensuite,
l’intégration de la technologie Blockchain dans le plan de sécurité et de respect de la vie
privée. Enfin, l’amélioration des plans de contrôle et de gestion.
3.2.2 Résumé
Dans cette section, nous avons identifié les limitations actuelles de l’architecture de
référence C-ITS, rendant impossible le déploiement de l’ensemble des applications C-
ITS. Ainsi, nous avons présenté dans un premier temps les limites propres à chacun
des plans de l’architecture de référence C-ITS : contrôle et données, gestion, sécurité
et respect de la vie privée. Dans un second temps, nous avons mis en avant une pro-
blématique globale, devant être prise en compte au niveau de l’ensemble des plans de
l’architecture C-ITS : le traitement des données.
3.3 Solutions technologiques

Certaines limitations de l’architecture de référence C-ITS (cf. Section 3.2.1) sont liées
aux technologies sur lesquelles s’appuie cette architecture. C’est notamment vrai pour
le manque de flexibilité, le manque de dynamicité et le manque de passage à l’échelle.
Pour surmonter ces limites, il semblerait donc pertinent de considérer d’autres solutions
technologiques.
C’est pourquoi, dans cette section, nous présentons certaines des solutions techno-
logies qui pourraient être envisagées. Tout d’abord, les réseaux définis logiciellement
(cf. Section 3.3.1.1) et les fonctions réseau virtualisées (cf. Section 3.3.2.1). Ensuite,
l’informatique en périphérie du réseau (cf. Section 3.3.3.1) et la Blockchain (cf. Section
3.3.4.1). Enfin, les données massives et l’intelligence artificielle (cf. Section 3.3.5.1).
38
3.3.1 SDN
Les réseaux définis logiciellement (SDN, Software Defined Networking) sont une pre-
mière technologie dont l’intégration dans l’architecture de communication C-ITS pour-
rait s’avérer pertinente. Dans cette section, nous présentons le concept (cf. Section
3.3.1.1), l’architecture (cf. Section 3.3.1.2) et les bénéfices (cf. Section 3.3.1.3) de SDN.
3.3.1.1 Concept
Dans les réseaux de communication traditionnels, les routeurs sont en charge de

deux opérations principales, la sélection du chemin de communication et le transfert de
données. On parle ainsi de plan de contrôle (sélection du chemin) et de plan de données
(transfert des données).
Habituellement, le plan de contrôle repose sur des prises de décision locales (prises
par le routeur lui-même) et des protocoles de routage distribués tels que OSPF (Open
Shortest Path First) ou BGP (Border Gateway Protocol). Ces protocoles permettent à
chaque routeur de récupérer des informations concernant l’état du réseau et de déter-
miner comment l’information doit être routée.
Néanmoins, cette approche présente une limite importante, le manque de flexibilité.
En effet, les fonctions de contrôle distribuées sont basées sur des règles de routage
pré-installées à la conception des équipements. Faire évoluer ces règles nécessiterait
une coûteuse et complexe modification de l’ensemble des routeurs. Aussi, faire évoluer
rapidement un réseau de grande envergure parait peu envisageable avec cette approche.
La technologie SDN pourrait permettre de surmonter ces limites. En effet, elle vise à
garantir une plus grande dynamicité, des évolutions rapides des politiques de contrôle
du réseau et une réduction des dépenses d’exploitation. Pour ce faire, cette technolo-
gie s’appuie sur une idée majeure : un découplage du plan de contrôle et du plan de
données.
Ainsi, avec SDN, les routeurs restent en charge du transfert des données mais ne
sont plus responsables de la sélection du chemin optimal. Cette prise de décision est
centralisée avec SDN et basée sur une connaissance de l’ensemble du réseau. Ceci doit
notamment permettre de garantir une meilleure prise de décisions, améliorant globale-
ment les performances du réseau.
Dans l’approche SDN, les prises de décision centralisées sont réalisées par un nouvel
39
élément, intégré à l’architecture : le contrôleur SDN. Ce contrôleur est connecté à l’en-

semble des équipements réseau et est en charge de la gestion de leurs tables de routage.
Pour ce faire, ces éléments envoient au contrôleur SDN différents types d’informations
(délai moyen de traitement d’un paquet, niveau de charge, etc) qui lui permettront
d’assurer les fonctions réseau : routage, équilibrage de charge, etc.
En fonction de l’étendue du réseau de communication, et du nombre de noeuds à
gérer, le plan de contrôle SDN peut être considéré comme centralisé ou logiquement
voire physiquement distribué [BSM18]. Dans ce second cas de figure (distribution),
plusieurs contrôleurs SDN sont utilisés. Chacun de ces contrôleurs gère une zone donnée
(et un ensemble d’équipements donné) du réseau et dispose d’une vision globale de
l’état du réseau grâce à des échanges avec les autres contrôleurs SDN (cf. Section 4.4.1).
SDN, découplant le plan de contrôle et le plan de données, représente une évolution
importante dans la façon de penser les réseaux de communication. Avec SDN, la table
de routage est remplacée au niveau de chaque routeur par une table des flux (Flow
Table). Celle ci est directement administrée par le contrôleur SDN et est utilisée par le
périphérique réseau pour gérer le transfert des données (cf. Annexe G .). Dans la section
suivante, l’architecture de communication de cette technologie est présentée.
3.3.1.2 Architecture
La technologie SDN repose sur un découplage du plan de contrôle et du plan de don-

nées. Ainsi, l’architecture de contrôle associée est composée de trois couches principales
(cf. Figure 3.1) :
— la couche de données : cette couche comprend l’ensemble des périphériques ré-

seau (routeurs, switches, RSU, véhicules, etc.) responsables du traitement et du
transfert des données. Dans un environnement tel que l’environnement véhicu-
laire, cette couche peut être décomposée en deux sous-couches. Tout d’abord, la
couche haute, correspondant aux connexions filaires. Ensuite, la couche basse,
correspondant aux connexions sans fil (V2V, V2I, etc.) ;
— la couche de contrôle : cette couche comprend le(s) contrôleur(s) SDN en charge

de la gestion des périphériques réseau composant le plan de données. Le contrô-
leur SDN convertit les demandes des applications SDN en règles de flux qu’il dé-
ploie au niveau des périphériques réseau : choix d’un chemin de communication,
40
allocation de bande passante, re-direction de paquets, etc. Le contrôleur doit éga-

lement être en capacité d’offrir une vue abstraite du réseau aux applications SDN.
Pour ce faire, il récupère des informations concernant l’état de l’ensemble des
équipements réseau (actif ou non, niveau de charge des ports, délais de traite-
ment d’un paquet, etc.) ;
— la couche applicative : cette couche correspond à l’ensemble des applications

SDN. Ces applications peuvent avoir différentes fonctionnalités : réservation de
bande passante, configuration de ports, pare feu, etc. En se basant sur la vue
abstraite de l’état du réseau, fournie par le contrôleur SDN, ces applications défi-
nissent leur besoins en terme de chemins de communication, bande passante, etc.
Ces besoins sont ensuite transmis au contrôleur SDN qui les convertit en règle de
flux et les déploie au niveau des équipements réseau.
A ces couches s’ajoutent également trois interfaces de communication (API, Applica-

tion Programming Interfaces) principales :
— L’interface sud (Southbound API) : cette interface correspond à l’interface entre

le contrôleur SDN et les périphériques réseau. Elle supporte différentes tâches :
remontée régulière d’informations au contrôleur, notification d’un évènement, dé-
ploiement de règles de flux, etc. Cette interface normalise les échanges entre la
couche de contrôle et la couche de données. Différents protocoles ont été conçus
pour cette couche. Le plus répandu d’entre eux est OpenFlow (cf. Annexe G .),
proposé par l’ONF (Open Networking Foundation). On peut également citer Net-
Conf/YANG 1 , proposé par l’ETSI, ou P4 2 , un langage de programmation pour
l’interface sud également soutenu par l’ONF. Il est à noter que dans le chapitre
4, nous nous concentrerons sur une approche SDN s’appuyant sur le protocole
OpenFlow ;
— les interfaces Est/Ouest (Eastbound/Westbound APIs) : ces interfaces corres-

pondent à deux types de communication [JZH+ 14]. Tout d’abord, des commu-
nications entre des contrôleurs SDN gérant différents domaines réseaux (interface
Ouest). Ensuite, des communications entre un plan de contrôle SDN et un plan
de contrôle d’un domaine non géré par SDN, par exemple géré par le protocole
1. https://tools.ietf.org/html/rfc6241
2. https://p4.org/p4-spec/docs/P4-16-v1.0.0-spec.html
41
F IGURE 3.1 – Architecture de communication SDN : Application aux réseaux

de communication véhiculaires 3
MPLS (MultiProtocol Label Switching). Ainsi, ces interfaces permettent un échange

d’informations nécessaires au routage inter-domaines ;
— l’interface nord (Northbound API) : cette interface correspond à l’interface entre
le plan de contrôle et le plan applicatif. Elle permet premièrement aux applica-
tions de disposer d’une vision globale de l’état du réseau, grâce aux informations
fournies par le contrôleur SDN. Elle permet également à ces applications de trans-
mettre des requêtes au contrôleur SDN : chemins de communication, bande pas-
sante, etc. Pour cette interface nord, l’architecture REST (Representational State
Transfer) est supportée par de nombreux contrôleurs SDN [TV16]. Cette approche,
couramment utilisée pour les services Web, présente de nombreux bénéfices : sim-
plicité de mise en place, légèreté, standardisation des échanges.
3.3.1.3 Bénéfices
L’application de cette technologie dans l’environnement véhiculaire pourrait per-

mettre de répondre à certaines des limites de l’architecture C-ITS (cf. Section 3.2.1) :
— la reconfiguration rapide du réseau : avec SDN, le contrôleur SDN dispose d’une

3. Source : https://link.springer.com/article/10.1007/BF03391543
42
vision globale de l’état du réseau. De plus, les périphériques réseau sont pro-
grammables. Ces deux caractéristiques pourraient permettre au contrôleur SDN
de reconfigurer en temps réel les chemins de communication en fonction des liens
existants. Elles pourraient également permettre au contrôleur de configurer des
chemins de communication futurs en fonction de la mobilité supposée des vé-
hicules et des autres usagers de la route (cf. Chapitre 4). Ainsi, avec SDN, une
reconfiguration rapide et efficace du réseau de communication devient possible
[YAA+ 17] ;
— la gestion optimale des ressources : les ressources à disposition (bande passante,
fréquence, canaux de communication) doivent être réparties de façon optimale
entre les différents utilisateurs. Ceci permet de garantir de bonnes performances
(latence, bande passante, perte de paquets) à chaque utilisateur du réseau. La
technologie SDN, offrant une vision globale de l’état du réseau, pourrait offrir une
gestion efficace de ces ressources [BC15] ;
— l’interopérabilité de réseaux hétérogènes : SDN standardise les échanges entre
équipements réseau et contrôleurs SDN. Ainsi, des équipements et réseaux hété-
rogènes pourraient être gérés conjointement. De plus, le plan de contrôle dispo-
serait d’une vision globale de l’état des différents réseau. Ainsi, l’approche SDN
pourrait permettre une gestion performante de réseaux hétérogènes et garantir
de meilleures performances de communication pour les utilisateurs [HKMVM16].
3.3.2 NFV
La virtualisation des fonctions réseau (NFV, Network Function Virtualization) est la
seconde technologie dont l’intégration dans l’architecture de référence C-ITS pourrait
être considérée. Dans cette section, nous présentons le concept (cf. Section 3.3.2.1) et
les bénéfices (cf. Section 3.3.2.2) de cette technologie.
3.3.2.1 Concept
L’utilisation de fonctions réseau (routage, filtrage, équilibrage de charge, etc.) repose

actuellement sur le déploiement d’équipements matériels dédiés propriétaires (routeur,
pare-feu, etc.). La mise en place de chaînes de service, ou l’augmentation de la capacité
d’une chaîne de service existante, nécessite donc l’achat et l’entretien d’un ensemble
d’équipements matériels coûteux et propriétaire.
43
La technologie de Virtualisation des Fonctions Réseau (NFV, Network Function Vir-

tualization), portée par l’ETSI et l’Open Networking Foundation (ONF), vise à résoudre
ce problème. En effet, NFV doit permettre d’offrir une version logicielle des fonctions
réseau et ainsi de dissocier fonctions réseau et équipements propriétaires matériels.
Cette technologie constitue donc une évolution importante dans la façon de conce-
voir, déployer et gérer les services réseau. Avec NFV, il devient possible de faire fonc-
tionner un routeur, un pare-feu ou un service de chiffrement dans une machine virtuelle
déployée sur un serveur X86 standard et non sur un matériel propriétaire.
Les avantages de cette approche sont nombreux. On peut tout d’abord parler d’une
réduction importante des coûts, tant d’achat que de maintenance. On peut également
évoquer une flexibilité accrue grâce à un déploiement flexible des machines virtuelles.
Enfin, associé à cette idée de flexibilité, un autre avantage important de l’approche lo-
gicielle est la possibilité de déployer rapidement de nouveaux services ou d’améliorer
rapidement des services existants. L’architecture de référence ETSI ISG NFV est présen-
tée en annexe (cf. Annexe A .).
3.3.2.2 Bénéfices
L’application de cette technologie dans les réseaux véhiculaires pourrait permettre

de répondre à certaines des limites de l’architecture C-ITS (cf. Section 3.2.1) :
— le support de différentes plateformes : la couche de virtualisation introduite

par l’approche NFV permet d’imaginer le déploiement de cette technologie sur
des plateformes variées, conçues par différents constructeurs. Ainsi, avec NFV, des
véhicules et des équipements de bord de route hétérogènes pourraient héberger
les mêmes applications et les mêmes fonctions réseau virtualisées, quelle que soit
la plateforme sous-jacente. Un fonctionnement global et homogène pourrait ainsi
être rendu possible [ZCC+ 16] ;
— l’accélération du cycle de vie des applications : la gestion du cycle de vie des

applications constitue un frein majeur au développement et à l’adoption des ré-
seaux véhiculaires [KAC+ 16]. Le basculement d’une approche matérielle vers une
approche logicielle permettrait un déploiement et une mise à jour efficaces de
fonctions réseau virtualisées. Ainsi, le temps nécessaire au déploiement et à l’éva-
luation de fonctions et applications réseau pourrait être fortement réduit ;
44
— un déploiement flexible : la densité étant variable (déplacement des véhicules),

l’architecture de communication doit pouvoir s’adapter à des niveaux de charge
différents. La virtualisation représente une solution pertinente pour garantir un
niveau de flexibilité élevé. En effet, les ressources pourraient être allouées dyna-
miquement en fonction des besoins des applications. Ceci garantirait à la fois le
bon fonctionnement des applications et une réduction des coûts de maintenance
[HVIP15].
3.3.3 Edge computing

L’informatique en périphérie du réseau (EC, Edge Computing) est une troisième tech-
nologie dont l’intégration dans l’architecture de référence C-ITS pourrait être perti-
nente. Dans cette section, nous présentons le concept (cf. Section 3.3.3.1) et les bé-
néfices (cf. Section 3.3.3.2) de cette technologie.
3.3.3.1 Concept
Le développement de nouveaux services se base aujourd’hui sur un paradigme essen-

tiel : l’informatique en nuage (Cloud Computing). Cette approche consiste à utiliser des
serveurs distants, publics ou privés, mis à disposition par des fournisseurs de services,
pour stocker et traiter des données. L’utilisateur n’est alors plus responsable du déploie-
ment et du maintien de l’infrastructure (Infrastructure as a Service), de la plateforme
(Platform as a Service), voire même de l’application qu’il souhaite utiliser (Software as
a Service). Ainsi, l’approche Cloud simplifie du point de vue de l’utilisateur le stockage
et le traitement des données. Elle permet également une réduction des coûts (achat
et maintenance), une grande flexibilité (quantité variable de ressources), une bande
passante importante et une fiabilité élevée [Cat09]. C’est pourquoi le développement
d’applications C-ITS basé sur une approche Cloud a été proposé dans de nombreux
travaux tels que [ASA+ 15, BM12].
Néanmoins, cette approche Cloud présente différentes limitations. Parmi ces limi-
tations, on peut citer la latence résultant de la centralisation du traitement des don-
nées [HPL+ 13]. Cette latence pourrait engendrer des problèmes de sécurité routière
ou de fluidité du trafic pour des applications nécessitant une réactivité importante.
Un autre point bloquant est le passage à l’échelle. En effet, avec un nombre de véhi-
cules en constante augmentation, la remontée d’informations non pré-traitées et non
45
filtrées pourrait entraîner un encombrement du réseau. Une troisième limitation est la

connexion internet nécessaire au fonctionnement de ce système. Sans cette connexion,
l’accès au service devient impossible. Dans l’environnement véhiculaire, un véhicule
n’étant pas nécessairement connecté en permanence, ceci pourrait également consti-
tuer un frein important. Une dernière limite potentielle est l’absence d’adaptation au
contexte. Pour nombre d’applications C-ITS (cf. 2.3.2.2), cette adaptation est nécessaire
et doit, par conséquent, être permise par l’architecture de communication.
C’est pourquoi, pour surmonter ces différentes limitations, un nouveau paradigme a
été introduit : l’informatique en périphérie du réseau (EC, Edge Computing). L’EC étend
l’approche Cloud aux bordures du réseau [MCK19a]. L’idée principale de l’EC est donc
d’offrir des services externalisés en bordure du réseau et non dans des centres de don-
nées (Data Centers) éloignés. Pour ce faire, l’EC utilise les capacités de communication,
de stockage et de calcul de l’ensemble des équipements du réseau : routeurs, stations
de base, véhicules, etc.
Cette technologie constitue donc une évolution importante dans la façon de pen-
ser les services externalisés. Contrairement à l’approche Cloud, avec l’EC, les opérations
sont réalisées au plus proche de l’utilisateur. Le déploiement de services flexibles, fiables
et sécurisés est donc garanti. De plus, l’EC répond aux limitations de l’approche Cloud :
latence, encombrement du réseau, nécessité d’une connexion Internet permanente, ab-
sence de prise en compte du contexte.
On peut noter que ce paradigme est porté par différents acteurs. D’un côté, les opé-
rateurs mobiles qui, menés par l’ETSI, ont introduit l’idée de Mobile Edge Computing
ou Multi-Access Edge Computing (MEC) [ETS17, ETS14]. D’un autre côté, les équipe-
mentiers réseau qui, portés par Cisco, ont introduit l’idée de Fog Computing [Com15].
Enfin, les fournisseurs de services qui, portés par Google, ont introduit l’idée de Cloudlet
[Sat14].
Ces différentes implémentations (MEC, Fog Computing, Cloudlet) ont un même ob-
jectif : déployer des services en bordure du réseau (cf. Figure 3.2). Toutefois, ces implé-
mentations se basent sur différents équipements (stations de base, routeur, micro ser-
veur) et différentes couches de virtualisation (Fog Abstraction Layer, NFV, OpenStack).
De plus, chacune de ces approches présente des bénéfices spécifiques : adaptation au
contexte, bande passante, latence, coût de déploiement, etc. Une comparaison de ces
différentes approches est accessible en annexe (cf. Annexe C .). L’architecture ETSI de
46
référence pour la technologie MEC est également présentée en annexe (cf. Annexe D .).
F IGURE 3.2 – Différentes approches d’informatique en périphérie du réseau
3.3.3.2 Bénéfices
L’application de la technologie EC dans les réseaux véhiculaires pourrait permettre

— un déploiement flexible : tout comme l’approche Cloud, l’EC permet un déploie-
ment flexible des applications. Les ressources sont allouées en temps réel en fonc-
tion des besoins des applications. Toutefois, l’approche EC, utilisant les ressources
en bordure du réseau, ouvre de nouvelles perspectives. En effet, il devient pos-
sible de déployer localement des ressources répondant aux besoins d’une applica-
tion donnée dans un lieu particulier. Ainsi, une faible latence et une disponibilité
élevée peuvent être garantis [Mäk15] ;
— un passage à l’échelle : utiliser les ressources des équipements réseau (Fog Com-
puting, MEC), ou déployer des serveurs supplémentaires (Cloudlet), permet d’ac-
croître la quantité de ressources de traitement et de stockage à disposition. Avec
cette approche, les échanges vers le Cloud et la quantité de bande passante utilisée
sont également réduits. Par conséquent, l’EC garantit un passage à l’échelle impor-
tant. Avec l’EC, l’augmentation du nombre de véhicules connectés et d’applications
véhiculaires pourraient donc être gérés efficacement ;
47
— un traitement efficace des données : certaines applications C-ITS, dépendantes

du contexte, nécessitent des délais de réponse courts (sécurité routière, fluidité du
trafic). Avec l’EC, les services nécessaires à ces applications seraient déployés en
bordure du réseau. Ainsi, les délais de traitement pourraient être réduits pour ces
applications [HPL+ 13] et l’adaptation au contexte pourrait être plus importante
[MCK19a]. L’EC pourrait donc garantir un traitement des données plus efficace.
3.3.4 Blockchain
La Blockchain (BC) est une quatrième technologie dont l’intégration dans l’architec-
ture de référence C-ITS pourrait s’avérer pertinente. Dans cette section, nous présentons
le concept (cf. Section 3.3.4.1), l’architecture (cf. Section 3.3.4.2) et les bénéfices (cf.
Section 3.3.4.3) de cette technologie.
3.3.4.1 Concept
La mise en place de services de sécurité et de protection de la vie privée repose gé-

néralement sur une solution centralisée, nommée Infrastructure à Clé Publique (PKI,
Public Key Infrastructure). Cette approche se base sur une idée simple. Une autorité
de confiance centrale (Autorité de Certification) garantit la fiabilité des informations
relatives à l’ensemble des utilisateurs du réseau (certificats). Cette approche, au fonc-
tionnement et à la fiabilité démontrés, a été adoptée par différents projets pilotes pour
le déploiement des C-ITS à l’image des projets SCOOP 4 et PRESERVE 5 .
Toutefois, les PKI présentent des limites [MCK20a]. La première d’entre elles est
l’existence d’une Autorité de Certification centrale, point de défaillance important et
unique du réseau. La compromission de cet élément pourrait entraîner une perte de
sécurité pour l’ensemble du réseau. Une autre limite importante est le manque de ré-
activité, notamment pour la gestion des révocation des certificats. Ainsi, un utilisateur
malveillant pourrait continuer à communiquer au détriment de la sécurité [YSW+ 18].
Une troisième limite est le manque de transparence dans la gestion des listes de révoca-
tion. Celles ci n’étant pas immuables, une autorité de certification peut la modifier sans
que les utilisateurs n’en soient informés.
4. http://www.scoop.developpement-durable.gouv.fr/en/components-a6.html
5. https://smartmobilitycommunity.eu/sites/default/files/Security_Preserve_2014.pdf
48
Afin d’offrir une réponse à ces différentes limitations, une nouvelle solution, décen-
tralisée, a été proposée : la Blockchain. Cette technologie, tout d’abord pensée pour
l’échange sécurisé de crypto-monnaies [Nak19], a été étendue à d’autres domaines,
dont les réseaux véhiculaires [MCK18]. La Blockchain permet de stocker et de trans-
mettre des informations sans organe central de contrôle (sans autorité de certification).
Ainsi, avec la Blockchain, un ensemble de noeuds, non dépendants d’une entité unique,
peuvent garantir l’intégrité d’un registre distribué. Cette intégrité est permise par l’uti-
lisation de mécanismes de consensus et de techniques de cryptographie.
La Blockchain est une évolution importante dans la façon de penser la sécurité des
réseaux. En effet, par opposition à une approche basée sur une PKI centralisée, la Block-
chain pourrait permettre le déploiement de PKI décentralisées. Cette évolution architec-
turale pourrait permettre de limiter les risques d’attaques liés à l’existence d’un unique
point d’attaque. Chaque noeud agissant indépendamment, l’attaquant devrait être en
mesure de prendre le contrôle de la majorité des noeuds pour pouvoir influencer le
comportement du réseau. De plus, cette technologie, conçue pour garantir une diffu-
sion rapide des informations entre les différents noeuds du réseau, pourrait permettre
une révocation des certificats plus efficace. Enfin, en mettant les informations à disposi-
tion de l’ensemble des noeuds du réseau et en garantissant l’immutabilité des données,
cette technologie offre un niveau de transparence plus important.
3.3.4.2 Architecture
Le fonctionnement de cette technologie repose sur différents éléments (cf. Figure

3.3) :
— la chaîne de blocs : il s’agit de la structure de données utilisée par la Blockchain

pour le stockage des informations : certificats, transactions monétaires, etc. Cette
structure, correspondant à une chaîne de blocs, est stockée au niveau de chacun
des noeuds du réseau. Elle permet de garantir l’immuabilité et la validité des in-
formations échangées entre les noeuds grâce à des techniques cryptographiques
(hashage, chiffrement) et d’horodatage ;
— le réseau pair-à-pair : il s’agit du réseau de communication permettant l’échange

direct entre les différents noeuds du réseau. Ce réseau pair-à-pair permet à tout
noeud de recevoir, vérifier et analyser les données échangées sur le réseau ;
49
— le mécanisme de consensus : il s’agit du protocole décentralisé garantissant la

sécurité du réseau. En l’absence d’une autorité centrale de vérification, l’ensemble
des noeuds doit pouvoir vérifier et valider les données contenues dans la chaîne
de blocs. Pour ce faire, différents mécanismes de consensus ont déjà été proposés
tels que [FCZ+ 19] : la Preuve de Travail (PoW, Proof of Work), la Preuve d’Enjeu
(PoS, Proof of Stake) ou la Preuve d’Autorité (PoS, Proof of Autority) ;
— les applications décentralisées : la technologie Blockchain permet également le

déploiement de services décentralisés. Ces applications décentralisées permettent
une automatisation des interactions entre l’utilisateur et les données présentes
dans la chaîne de blocs. Cette automatisation repose sur des programmes infor-
matiques pouvant être déployés dans cet environnement : les contrats intelligents
(smart contracts) [PD+ 18]. Ces contrats intelligents sont des logiciels déployés au
niveau de chaque noeud Blockchain et intégrés à la chaîne de bloc. L’ensemble des
noeuds autorisés peuvent exécuter un contrat intelligent donné. Lorsque l’action
demandée requiert la modification de la chaîne de bloc, l’ensemble des noeuds
vérifient les informations générées par le contrat intelligent.
F IGURE 3.3 – Architecture de la Blockchain 6
6. Source : Coindesk https://www.coindesk.com/blockchain-application-stack
50
3.3.4.3 Bénéfices
L’application de cette technologie dans les réseaux véhiculaires pourrait permettre

— une sécurité accrue : avec la technologie Blockchain, un environnement sécurisé

peut être mis en place sans nécessiter l’intervention d’un tiers de confiance. Par
conséquent, avec cette approche le point de défaillance unique existant dans les
architectures de sécurité traditionnelles n’existe plus. Un niveau de sécurité plus
élevé est donc garanti [KKM19] ;
— un passage à l’échelle important : dans l’approche classique, la validation et la
vérification des identités reposent sur un nombre très limité de noeuds. Ceci qui
pourrait constituer une limite dans le cadre du déploiement à large échelle de
véhicules connectés [CHC16]. La Blockchain, composée d’un ensemble important
de noeuds, intervenant chacun dans le processus de validation, pourrait offrir une
réponse à cette limite. Ainsi, cette technologie pourrait permettre de garantir un
accès rapide aux services de sécurité pour l’ensemble des composants IoV ;
— l’établissement de confiance : en l’absence de connectivité Internet, l’accès aux
services de sécurité devient impossible pour les approches traditionnelles. Or, l’éta-
blissement de confiance est nécessaire à chaque instant. La technologie Block-
chain, déployée localement, pourrait permettre de contrôler la fiabilité des mes-
sages et des émetteurs sans nécessiter une connexion Internet. Ainsi, le niveau de
confiance entre noeuds véhiculaires pourrait être renforcé [MCK20b].
3.3.5 Données massives et Intelligence Artificielle

Les techniques de traitement de données massives (Big Data) et d’Intelligence Ar-
tificielle (AI, Artificial Intelligence) sont une cinquième composante dont l’intégration
dans l’architecture de référence C-ITS pourrait être pertinente. Dans cette section, nous
présentons le concept (cf. Section 3.3.5.1) et les bénéfices (cf. Section 3.3.5.2) de ces
technologies.
3.3.5.1 Concept
Les réseaux de communication actuels génèrent des quantités importantes d’infor-

mations : géo-localisation, durée des appels, utilisation des applications, etc. Une uti-
51
lisation efficace de ces informations pourrait permettre aux opérateurs d’optimiser les
coûts et le fonctionnement de services existants : déploiement, maintenance, allocation
de ressources, sécurité, routage, etc. De nouveaux revenus pourraient également être
générés [HYZ+ 16]. Aussi, le traitement de ces informations est apparu comme un axe
de développement majeur.
Néanmoins, le stockage, l’accès et le traitement de volumes de données aussi impor-
tants est impossible avec les méthodes traditionnelles de stockage et d’accès. C’est pour
cette raison que de nouveaux outils destinés au traitement de données massives (Big
Data), notamment portés par les fournisseurs de services (Google, Microsoft, etc.) ont
vu le jour. Ces outils permettent la collecte de données depuis des sources multiples,
l’agrégation et le traitement de volumes de données massifs. Apache Hadoop et Apache
Spark [ROOA15] sont parmis les outils de Big Data les plus utilisés.
Toutefois, la plus-value de ces plateformes ne réside pas uniquement dans le sto-
ckage et dans l’accès à ces données. En effet, ce sont les traitements qui pourront être
réalisés sur ces données qui permettront des prises de décision bénéfiques à la gestion
du réseau [Wan12]. Pour ce faire, les techniques d’Intelligence Artificielle (IA) sont au-
jourd’hui une approche fortement plébiscitée. En effet, grâce au développement d’équi-
pements aux capacités de calcul importantes, l’application de techniques d’IA à des
volumes de données importants est devenue possible. Ainsi, des modèles de prédiction
fiables peuvent être développés et implémentés.
En couplant une collecte et un traitement efficaces de données massives (Big Data)
à des modèles de prédiction performants (IA), la gestion, le contrôle et la sécurité
pourraient être améliorés. Aussi, l’application de ces technologies à l’environnement
véhiculaire, soumis à des variations importantes (mobilité, pic horaires, etc.), semble
pertinente.
3.3.5.2 Bénéfices
Comme nous l’avons noté dans la section 3.2.1, le traitement intelligent des données
est un problème commun à l’ensemble des plans de l’architecture de référence C-ITS.
Aussi, l’application des technologies Big Data et IA dans l’environnement véhicu-
laire pourrait s’avérer bénéfique pour les différents plans de l’architecture C-ITS. Tout
d’abord, pour le plan de contrôle au travers d’une gestion optimale des ressources, d’une
reconfiguration rapide du réseau, et d’une meilleure interopérabilité. Ensuite, pour le
52
plan de gestion au travers d’un déploiement plus flexible et d’une accélération du cycle
de vie des applications. Enfin, pour le plan de sécurité et de respect de la vie privée au
travers d’un passage à l’échelle plus important et d’un niveau de confiance plus élevé.
Une présentation plus détaillée des bénéfices du traitement intelligent des données pour
les réseaux véhiculaires sera faite dans les sections 3.4.2 et 3.5.4.
3.3.6 Résumé
Dans cette section, nous avons introduit différentes solutions technologiques qui
pourraient être intégrées aux réseaux véhiculaires pour répondre aux limites de l’ar-
chitecture de référence C-ITS. Ces technologies sont la technologie SDN (cf. Section
3.3.1.1), la technologie NFV (cf. Section 3.3.2.1), la technologie EC (cf. Section 3.3.3.1),
la technologie Blockchain (cf. Section 3.3.4.1) et les technologies de données massives
et d’IA (cf. Section 3.3.5.1). Pour chacune de ces technologies, nous avons présenté le
concept et les bénéfices que pourraient présenter leur intégration dans l’environnement
véhiculaire. Pour certaines d’entre elles (SDN, Blockchain), nous avons également mis
en avant l’architecture sur laquelle repose leur fonctionnement.
3.4 Architectures IoV existantes

Différentes solutions technologiques pourraient être intégrées dans l’architecture de
communication véhiculaire (cf. Section 3.3) : SDN, NFV, EC, Blockchain et données mas-
sives et IA. Chacune de ces technologies pourrait permettre de répondre partiellement
aux limites de l’architecture de référence C-ITS (cf. Section 3.2.1).
Aussi, de nombreux travaux de recherche se sont intéressés à l’association de ces
technologies dans l’environnement véhiculaire. Les évolutions proposées peuvent avoir
différents objectifs : amélioration du plan de gestion (cf. Section 3.4.1), amélioration du
plan de contrôle et de données (cf. Section 3.4.2) et amélioration du plan de sécurité et
de respect de la vie privée (cf. Section 3.4.3). Toutefois, certaines évolutions sont encore
nécessaires pour répondre aux besoins de l’ensemble des applications C-ITS (cf. Section
3.4.4).
3.4.1 Amélioration du plan de gestion

Pour répondre aux limites du plan de gestion (support de différentes plateformes,
accélération du cycle de vie des applications, déploiement flexible), trois technologies
53
semblent pertinentes (cf. Section 3.3) : NFV, SDN et les techniques de traitement intel-
ligent des données.
Pour ce qui est de la technologie NFV, deux papiers ont suggéré son intégration dans
l’architecture de référence C-ITS : [CMIM17, KLBLa18]. Les auteurs de [CMIM17] ont
mis en avant les bénéfices de NFV pour la gestion des ressources. Pour ce faire, ils ont
tout d’abord proposé la définition d’un plan de gestion et d’orchestration basé sur NFV.
Puis, au travers d’un exemple concret (service de conduite autonome), ils ont évalué
l’intérêt de cette technologie à différents niveaux : terminaux utilisateurs, réseau d’accès
radio et coeur du réseau. Allant plus loin, les auteurs de [KLBLa18] ont proposé une
implémentation et une évaluation de réseaux véhiculaires basés sur la technologie NFV.
Cette étude a permis de confirmer les bénéfices de NFV tant en termes de déploiement
que d’adaptabilité (bande passante, latence, perte de paquets).
Pour ce qui est des techniques de traitement intelligent des données, les auteurs de
[CTF+ 18, AAK+ 18] ont proposés leur intégration dans l’architecture de référence C-
ITS. Ils ont notamment considéré l’utilisation de ces techniques, en complément de la
technologie NFV, pour garantir une analyse fine des performances du système et une
allocation optimale des ressources. Cette allocation de ressources est considérée à deux
niveaux. Au niveau d’une station C-ITS, ces techniques pourraient être utilisées pour
allouer les ressources entre les applications uniquement dépendantes de cette station :
divertissement, sécurité routière, etc. A un niveau plus global, elles pourraient être uti-
lisée par des applications telles que le Cloud Vehiculaire (VCC, Vehicular Cloud Com-
puting) [WSGB14] ou l’EC Véhiculaire (VEC, Vehicular Edge Computing) [HLC+ 16]. En
effet, les applications VEC et VCC nécessitent une répartition de tâches et de ressources
entre différents noeuds de calcul dont les performances pourraient être améliorées par
un traitement efficace des données.
Enfin, l’intégration de la technologie SDN dans le plan de gestion a été considérée
dans [BOV17]. Bien que principalement destinée au le plan de contrôle, cette technolo-
gie pourrait également permettre une gestion globale des communications. A cet effet,
les auteurs de [BOV17] ont proposé d’ajouter au plan de gestion un nouvel élément,
le gestionnaire de réseau. Ce gestionnaire de réseau, s’appuyant sur un contrôleur SDN
central (P-SDNC, Primary-SDN Controller), doit rendre possible une gestion globale du
plan de contrôle du réseau. Il s’agit notamment de la définition de politiques de routage
(ou de pare-feu) communes à l’ensemble des équipements réseau.
54
3.4.2 Amélioration du plan de contrôle et de données

Le plan de contrôle et de données est celui sur lequel se sont concentrés l’essentiel
des améliorations architecturales proposées jusqu’ici (cf. Section 3.2.1). Pour répondre
aux limites identifiées pour ce plan de contrôle et de données (reconfiguration rapide
du réseau, gestion optimale des ressources, interopérabilité de réseaux hétérogènes),
trois technologies semblent pertinentes (cf. Section 3.3) : le SDN, l’EC et les techniques
de traitement intelligent des données.
Pour ce qui est de la technologie SDN, différents papiers ont considéré son intégra-
tion dans l’architecture de référence C-ITS : [JHN+ 16, BOV17, CBM17]. Les auteurs
de [JHN+ 16] sont les premiers à avoir proposé l’introduction d’un plan de contrôle
SDN pour la gestion la mobilité des utilisateurs et l’hétérogénéité des technologies d’ac-
cès radio. Ils ont également introduit l’idée d’un plan de données (cf. Section 3.3.1.2)
décomposé en deux sous-couches. D’un côté, une sous-couche haute correspondant à
l’infrastructure physique : RSU, BS, etc. D’un autre côté, une sous-couche basse cor-
respondant à l’infrastructure mobile : véhicule, piétons, etc. Pour gérer au mieux ce
plan de données et garantir une importante réactivité du plan de contrôle, les auteurs
de [JHN+ 16, BOV17] ont défini un plan de contrôle distribué et hiérarchique. Ce plan
est composé d’un ensemble de contrôleurs SDN déployés. Développant cette idée, dans
[CBM17], le déploiement de contrôleurs SDN a été également proposé pour permettre
un traitement des données distribué associant AI et EC [WHW+ 19, WYQM18].
L’intégration de techniques de traitement intelligent des données a été considérée
dans différents papiers, au travers de trois approches principales :
— l’intégration de techniques de traitement intelligent des données au sein d’une

couche du plan de contrôle et de données : cette idée, portée par de nombreux
papiers [KAC+ 16, AAK+ 18, BOV17], consiste à faire évoluer la couche Facilities de
l’architecture de référence C-ITS vers une couche nommée Intelligence Artificielle.
La mise en place de techniques de Big Data pourrait permettre un traitement effi-
cace des informations provenant des couches inférieures. Ainsi, le fonctionnement
des applications nécessitant le traitement de volumes massifs de données pour-
rait être amélioré, notamment la gestion de trafic [AAK+ 18]. Cette couche d’IA
pourrait également permettre une analyse statistique des données au service des
fournisseurs de services. Ainsi, la définition de modèles économiques et la com-
55
mercialisation des réseaux de communication véhiculaires pourrait être favorisée

[KAC+ 16]. Enfin, cette couche pourrait améliorer les performances des couches
inférieures, notamment de la couche Networking and Transport, en couplant IA et
SDN [BOV17] ;
— l’intégration de techniques de traitement intelligent des données au sein de plu-

sieurs couches du plan de contrôle et de données : le traitement des données n’est
pas uniquement nécessaire pour les couches Facilities et Networking and Trans-
port mais également pour la couche Access. Aussi, l’intégration de techniques d’IA
et de Big Data est proposée à différents niveaux de l’architecture C-ITS. Comme
cela est indiqué dans [CCZGI17b], ceci pourrait permettre un pré-traitement des
données, une sélection dynamique de la technologie d’accès radio et un contrôle
optimal des communications. L’IA pourrait également être déployée au niveau des
applications elles mêmes (auto-réparation du véhicule, surveillance de la santé du
conducteur, analyse des émotions, etc.) comme cela est proposé dans [CTF+ 18] ;
— la définition d’un plan de connaissance associé au plan de contrôle et de données :

cette idée, introduite dans [JHN+ 16], doit permettre d’améliorer les prises de dé-
cision inter-couches. Ainsi, le traitement des informations provenant des couches
basses (données) pourrait être adapté aux besoins des couches hautes (contrôle,
application). Associé à la technologie SDN, ce plan de connaissance rendrait pos-
sible une meilleure gestion de la mobilité et de l’hétérogénéité des ressources :
contrôle de transmission, handovers etc.
Enfin, l’intégration de la technologie EC a été considérée dans [BOV17, CMIM17,

ZZC17]. Ces travaux proposent le déploiement de l’EC au sein de la couche Facilities.
L’EC permettrait notamment de traiter localement les données et d’améliorer les per-
formances des outils d’IA [BOV17]. En effet, comme cela a été noté dans [ZZC17],
l’utilisation de l’EC pour le déploiement d’IA [BOV17] ou de Big Data [ZZC17] garan-
tirait une réactivité plus importante et une meilleure prise en compte du contexte. De
plus, cette approche pourrait être couplée à une approche Cloud centralisée [CMIM17].
Ainsi, des prises de décisions globales (Cloud), à long terme, pourraient compléter les
prises de décisions locales (EC), immédiates.
56
3.4.3 Amélioration du plan de sécurité et de respect de la vie privée

Pour répondre aux limites du plan de sécurité et de respect de la vie privée (sécurité
accrue, passage à l’échelle, établissement de confiance), deux technologies semblent
pertinentes (cf. Section 3.3) : la Blockchain et les techniques de traitement intelligent
des données.
Les auteurs de [CCZGI17a, CCZGI17b] ont ciblé la sécurité et le respect de la vie
privée comme un axe de développement essentiel. Ils ont notamment identifié les be-
soins principaux en terme d’authentification, confidentialité, contrôle d’accès, non ré-
pudiation, disponibilité et anti-jamming. Il ont également décrit des axes d’amélioration
similaires à ceux que nous avons mis en avant : réduction des coûts, robustesse, pas-
sage à l’échelle et gestion d’un nombre important de noeuds. Néanmoins, ces papiers
portent uniquement sur l’identification des limitations et non sur la définition de solu-
tions. De plus, aucune des autres évolutions proposées jusqu’ici ne considère les besoins
du plan de sécurité et de respect de la vie privée. Aussi, la prise en compte de ce plan
dans la définition d’une nouvelle architecture C-ITS (cf. Section 2.3.4) apparaît comme
nécessaire.
3.4.4 Comparaison
De nombreuses améliorations de l’architecture de référence C-ITS (cf. Section 2.3.4)
ont déjà été proposées dans la littérature. Ces travaux (cf. Tableau 3.1) peuvent être
classés en trois catégories :
— ceux qui se concentrent sur l’amélioration d’un seul plan au travers de l’inté-
gration d’une seule technologie :
• les auteurs de [KLBLa18] proposent l’intégration de la technologie NFV dans

le plan de gestion ;
• les auteurs de [CBM17] proposent l’intégration de la technologie SDN dans

le plan de contrôle et de données ;
• les auteurs de [ZZC17] proposent l’intégration de la technologie EC dans le

plan de contrôle et de données ;
• les auteurs de [CCZGI17b, KAC+ 16] proposent l’intégration de techniques de

traitement intelligent des données dans le plan de contrôle et de données ;
57
Tableau 3.1 – Comparaison des différentes évolutions architecturales proposées
SDN AI
Approches NFV EC Blockchain
MP CDP MP CDP SSP
[KLBLa18] Oui Non Non Non Non Non Non Non
[CMIM17] Oui Non Non Oui Non Non Non Non
[AAK+ 18] Oui Non Non Non Simple Non Non Non
Multi
[CTF+ 18] Oui Non Non Non Oui Non Non
couche
Multi
[BOV17] Non Oui Oui Non Simple Non Non
couche
[JHN+ 16] Non Non Simple Non Non Plan Non Non
Multi
[CBM17] Non Non Non Non Non Non Non
couche
[KAC+ 16] Non Non Non Non Non Simple Non Non
Multi
[CCZGI17b] Non Non Non Non Non Non Non
couche
[ZZC17] Non Non Non Oui Non Non Non Non
Multi
Proposition Oui Oui Oui Plan global Oui
couche
— ceux qui se concentrent sur l’amélioration d’un seul plan au travers de l’inté-
gration de différentes technologies :
• les auteurs de [AAK+ 18] proposent l’intégration de la technologie NFV et de

techniques de traitement intelligent des données dans le plan de gestion ;
• les auteurs de [JHN+ 16] proposent l’intégration de la technologie SDN et de

techniques de traitement intelligent des données dans le plan de contrôle et
de données ;
— ceux qui proposent l’amélioration de différents plans au travers de diffé-

rentes technologies :
• les auteurs de [CMIM17] proposent l’intégration de la technologie NFV au

sein du plan de gestion et de la technologie EC au sein du plan de contrôle et
de données ;
• les auteurs de [BOV17] proposent l’intégration de la technologie EC et de

techniques de traitement intelligent des données au sein du plan de contrôle
58
et de données. Ils considèrent également l’intégration de la technologie SDN

au sein des plans de gestion et de contrôle et de données ;
• les auteurs de[CTF+ 18] proposent l’intégration de la technologie NFV au sein

du plan de gestion. Ils considèrent également l’intégration de techniques de
traitement intelligent des données au sein des plans de gestion et de contrôle
et de données.
F IGURE 3.4 – Architecture C-ITS combinant l’ensemble des améliorations proposées
L’architecture présentée en figure 3.4 combine l’ensemble des améliorations propo-

sées jusqu’ici dans la littérature. Les blocs blancs représentant les éléments intégrés à
l’architecture de référence C-ITS. Cette évolution architecturale permet de répondre à
une grande partie des limitations (cf. Section 3.2.1) de l’architecture C-ITS de réfé-
rence :
— l’intégration des technologies NFV, SDN et des techniques de traitement intelligent

des données au sein du plan de gestion permet de répondre aux limites identifiées
59
pour ce plan. Le support multi-plateformes mais également l’accélération du cycle

de vie des applications et la flexibilité du déploiement ;
— l’intégration des technologies SDN, EC et des techniques de traitement intelligent

des données au sein du plan de contrôle et de données permet de répondre aux li-
mites identifiées pour ce plan. La reconfiguration rapide du réseau mais également
la gestion optimale des ressources et l’interoperabilité des réseaux hétérogènes.
Toutefois, dans cette architecture :
— les limites du plan de sécurité et de respect de la vie privée ne sont pas

traitées : les limites en terme de sécurité et de respect de la vie privée de l’ar-
chitecture de référence C-ITS (passage à l’échelle, sécurité accrue, établissement
de confiance) on été identifiées dans dans [CCZGI17a, CCZGI17b]. Toutefois, au-
cune solution n’a été proposés pour y répondre. Aussi, une évolution de ce plan
est nécessaire ;
— le traitement intelligent des données est insuffisant : les traitements réalisés

au niveau des plans de contrôle et de gestion sont décorrélés, bien que se basant
sur les mêmes données. Ceci implique par conséquent une duplication de cer-
taines actions et un gaspillage de ressources (stockage, calcul, communication).
De même, les traitements au niveau des différentes couches du plan de contrôle et
de données (Networking and Transport, Facilities) sont réalisés de façon indépen-
dante. Or, certains protocoles multi-couches (SDN) pourraient nécessiter un par-
tage d’informations entre différentes couches. De même, les informations concer-
nant le contexte pourraient être utiles au niveau de différentes couches. Enfin,
l’intégration de techniques de traitement intelligent des données n’est pas consi-
dérée pour le plan de sécurité et de respect de la vie privée. Aussi, une évolution
dans l’approche utilisée pour le traitement des informations est nécessaire.
Ainsi, les améliorations proposés jusqu’ici dans la littérature ne répondent pas à l’en-
semble des limites de l’architecture de référence. De plus, aucun des travaux existants
n’a proposé l’ensemble des évolutions présentées en figure 3.4. Aussi, la proposition
d’une nouvelle architecture apparaît comme nécessaire. Cette ci se présentée dans la
section 3.5.
60
3.4.5 Résumé
Dans cette section, nous présentons les améliorations de l’architecture de référence
C-ITS proposées jusqu’ici dans la littérature. Pour ce faire, nous commençons par lis-
ter les améliorations introduites pour le plan de gestion (cf. Section 3.4.1), le plan de
contrôle et de données (cf. Section 3.4.2) et le plan de sécurité et de respect de la vie
privée (cf. Section 3.4.3). Dans un second temps (cf. section 3.4.4), les solutions exis-
tantes sont comparées et leurs limites sont identifiées (traitement des données, sécurité
et respect de la vie privée). Afin de répondre à ces limites, une nouvelle architecture
sera introduite dans la section suivante (cf. Section 3.5).
3.5 Une nouvelle architecture pour l’IoV

Différentes évolutions de l’architecture de référence C-ITS (cf. Section 3.4) ont déjà
été proposées. Néanmoins certaines limitations de cette architecture (cf. Section 3.2.1)
n’ont pas encore été considérées. Il s’agit notamment des limites du plan de sécurité et
de respect de la vie privée et de la définition d’un traitement global des données.
C’est pourquoi, dans cette section, nous proposons une nouvelle architecture pour
les communications véhiculaires (cf. Section 3.5.1). Celle ci s’appuie sur l’architecture
de référence C-ITS et répond aux limites actuelles de l’IoV. Elle combine l’ensemble
des évolutions déjà considérées dans la littérature (cf. Section 3.5.2) et intègre deux
améliorations. Tout d’abord, la technologie Blockchain dans le plan de sécurité et de
respect de la vie privée (cf. Section 3.5.3.1). Ensuite, un plan de connaissance au service
de l’ensemble de l’architecture de communication (cf. Section 3.5.4). Pour chacun des
points considérés (combinaison, Blockchain, plan de sécurité), nous présentons leurs
bénéfices (cf. Sections 3.5.2.1, 3.5.3.1, 3.5.4.1) ainsi que la façon dont ils seront mis en
application dans la suite de cette thèse (cf. Sections 3.5.2.2, 3.5.3.2, 3.5.4.2).
3.5.1 Présentation globale

L’architecture proposée (cf. Figure 3.5) introduit trois évolutions importantes par
rapport aux architectures C-ITS définies dans la littérature (cf. Section 3.4). Tout
d’abord, la combinaison de l’ensemble des améliorations proposées jusqu’ici. Ensuite,
l’intégration de la technologie Blockchain dans le plan de sécurité et de respect de la vie
privée. Enfin, l’ajout d’un quatrième plan, le plan de connaissance. Ainsi, l’architecture
61
est maintenant composée des :
— plan de gestion : gérant globalement les ressources et l’architecture de commu-

nication. Son fonctionnement repose ici sur deux technologies principales (SDN,
NFV) et sur des interactions avec le plan de connaissance (cf. Section 3.5.4). Les
bénéfices de cette implémentation du plan de gestion sont présentés dans la sec-
tion 3.5.2 ;
— plan de contrôle et de données : chargé de la récupération, du transport et de

la distribution optimale de l’information. Son fonctionnement repose ici sur les
technologies EC et SDN et sur des interactions avec le plan de connaissance (cf.
Section 3.5.4). Les bénéfices de cette implémentation du plan de contrôle et de
données sont présentés dans la section 3.5.2 ;
— plan de sécurité et de respect de la vie privée : offrant des services de sécurité et

de protection de la vie privée à l’ensemble des autres plans : autorisations, contrôle
d’accès, gestion de profils, etc. Son fonctionnement repose ici sur la technologie
Blockchain et sur des interactions avec le plan de connaissance (cf. Section 3.5.4).
Les bénéfices de cette implémentation du plan de sécurité et de respect de la vie
privée sont présentés dans la section 3.5.3 ;
— plan de connaissance : offrant des services de traitement et d’analyse de l’in-

formation, ainsi qu’une aide à la prise de décision, à l’ensemble des autres plans
(gestion, contrôle et données, sécurité et respect de la vie privée). Son fonction-
nement et ses bénéfices sont présentés dans la section 3.5.4.
Il est à noter que sur la figure 3.5, les éléments déjà proposés dans la littérature
(cf. Section 3.4), et combinés ici (SDN, NFV, EC), sont représentés par une couleur
sombre (gris foncé). Les nouveaux éléments, introduits dans notre approche (plan de
connaissance, Blockchain), sont représentés par une couleur blanche. Enfin, les élément
représentés par une couleur claire (gris clair) correspondent aux éléments déjà présents
dans l’architecture de référence C-ITS (cf. Section 2.3.4).
3.5.2 Combinaison des améliorations existantes

Dans cette section, nous présentons les bénéfices résultants de la combinaison des
améliorations déjà proposées dans la littérature (cf. Section 3.5.2.1). Nous mettons éga-
62
F IGURE 3.5 – Architecture C-ITS proposée
lement en avant la façon dont certaines de ces améliorations technologiques seront étu-
diées dans la suite de cette thèse (cf. Section 3.5.2.2).
3.5.2.1 Bénéfices
Les solutions technologiques déjà considérées dans la littérature et reprises ici sont :
SDN (cf. Section 3.3.1.1), NFV (cf. Section 3.3.2.1) et EC (cf. Section 3.3.3.1). Comme
cela est visible en figure 3.5, la technologie NFV est intégrée au plan de gestion. La
technologie EC est intégrée au plan de contrôle et de données. La technologie SDN est
elle intégrée à ces deux plans (gestion, contrôle). Les bénéfices résultant de l’intégration
de ces technologies (cf. Section 2.3.4) sont :
— pour le plan de gestion : l’intégration des technologies NFV (cf. Section 3.3.2.2)
et SDN (cf. Section 3.3.1.3) pourrait permettre de surmonter les limites de ce
plan :
• le support de différentes plateformes : la technologie NFV fournit une couche

de virtualisation (cf. Annexe A .) et la technologie SDN permet l’abstraction
du plan de données (cf. Section 3.3.1.2). La combinaison de ces mécanismes
63
rend envisageable le déploiement de services C-ITS sur tout type de plate-

forme (véhicules, équipements de bord de route, etc.) [ZCC+ 16] ;
• l’accélération du cycle de vie des applications : le basculement des applica-
tions réseau vers une approche logicielle (NFV) pourrait simplifier la main-
tenance et la mise à jour de ces applications. Ainsi, le cycle de vie de ces
applications pourrait être accéléré [HVIP15] ;
• un déploiement flexible : la gestion virtuelle des ressources (NFV, SDN) per-
met de les allouer (stockage et calcul [WLW+ 16], réseau [AX14, BOV17])
en fonction des besoins des applications et de l’évolution de la demande. La
réactivité et l’adaptabilité pourraient donc être plus importants.
— pour le plan de contrôle et de données : l’intégration des technologies SDN (cf.
Section 3.3.1.3) et EC (cf. Section 3.3.3.2) pourrait permettre de répondre aux
limites de ce plan :
• la reconfiguration rapide du réseau : la technologie SDN permet de gérer dy-
namiquement les règles de flux déployées au niveau des équipements réseau :
véhicules, équipements de bord de route, etc. L’application de cette techno-
logie pourrait donc permettre une prise en compte rapide des changements
de topologie [YAA+ 17] ;
• la gestion optimale des ressources : le contrôleur SDN dispose d’une vision
centralisée de l’état du réseau. Il pourrait donc être en mesure de répartir au
mieux les ressources (bande passante, canaux de communication) entre les
différentes applications et les différents utilisateurs. La technologie EC, quant
à elle, pourrait permettre un traitement local des données. Ainsi la quantité
de données remontées pourrait être limitée et une meilleure utilisation des
ressources garantie [MCK19a] ;
• l’interopérabilité de réseaux hétérogènes : la technologie SDN standardise les
échanges entre équipements réseau, contrôleur SDN et applications. Aussi,
cette technologie pourrait permettre une gestion conjointe de différents équi-
pements, et donc de réseaux hétérogènes. Par conséquent, une gestion opti-
male des ressources à disposition pourrait être garantie [HKMVM16].
La combinaison des améliorations déjà proposées dans la littérature permet donc de
répondre à la plupart des limites identifiées pour les plans de gestion et de contrôle et
64
données. Ces améliorations associées à un plan de connaissance (cf. Section 3.5.4) et à

un plan de sécurité et de respect de la vie privée renforcé (cf. Section 3.5.3) pourraient
donc permettre le déploiement de l’ensemble des applications C-ITS.
3.5.2.2 Mise en application
Les travaux menés dans cette thèse portent sur la définition d’une approche logicielle
pour la distribution géographique des données dans l’IoV. La technologie SDN occupera
donc une place importante dans les Chapitres 4 et 5.
En effet, dans la suite de ce document, nous nous proposons de :
— démontrer l’intérêt de cette technologie pour la distribution géographique des

données (cf. Chapitre 4) ;
— introduire une évolution du fonctionnement de cette technologie pour garantir de

meilleures performances dans un environnement mobile (cf. Chapitre 4) ;
— définir des mécanismes permettant de garantir une authentification et un contrôle

d’accès efficaces des composants SDN (cf. Chapitre 5).
Pour ce qui est des technologies NFV et EC, leur intégration dans l’architecture de
référence C-ITS parait essentielle pour répondre aux besoins des applications C-ITS. Ces
technologies ne sont pas directement abordées dans la suite de ces travaux. Toutefois,
les solutions proposées dans les chapitres 4, 5 pourraient s’appuyer sur ces technologies
pour leur déploiement. Par exemple, pour permettre un déploiement efficace des contrô-
leurs SDN, un approche logicielle, basée sur NFV pourrait être considérée [MVC+ 15].
De même, le déploiement des services de sécurité considérés pourrait être réalisé dans
un environnement EC [YYS+ 19].
3.5.3 Intégration de la technologie Blockchain dans le plan de sé-

curité et de respect de la vie privée
Dans cette section, nous présentons les bénéfices qui pourraient résulter de l’intégra-
tion de la technologie Blockchain dans le plan de sécurité et de respect de la vie privée
(cf. Section 3.5.3.1). Nous mettons également en avant la façon dont cette technologie
sera étudiée dans la suite de cette thèse (cf. Section 3.5.3.2).
65
3.5.3.1 Bénéfices
L’amélioration du plan de sécurité et de respect de la vie privée n’a pas été considérée
jusqu’ici. Pourtant, de nombreux travaux ont démontré les limites actuelles de ce plan
[CCZGI17a, CCZGI17b].
C’est pourquoi, nous proposons d’intégrer dans ce plan de sécurité et de respect de la
vie privée une nouvelle technologie : la Blockchain (cf. Section 3.3.4.1). Cette technolo-
gie supporte le déploiement des principales fonctions de sécurité et de respect de la vie
privée (authentification, intégrité, confidentialité, disponibilité, contrôle d’accès, non
répudiation, anonymat). Elle permet également de répondre aux challenges identifiés
pour le plan de sécurité et de respect de la vie privée :
— une sécurité accrue : comme indiqué dans la section 3.3.4.2, la technologie Blo-
ckchain s’appuie sur une architecture décentralisée composée d’un ensemble de
noeuds indépendants. Ainsi, avec cette technologie, la sécurité ne repose plus sur
un noeud central, à l’image d’une Autorité de Certification dans les approches clas-
siques, mais sur un ensemble de noeuds. Ceci permet notamment d’éliminer l’exis-
tence d’un point de défaillance unique (single point of failure). Par conséquent, la
sécurité, la disponibilité et la résilience du système de sécurité sont améliorés
[YSW+ 18] ;
— un passage à l’échelle important : avec la Blockchain, la gestion des fonctions
de sécurité (disponibilité, confidentialité, etc.) ne repose plus sur un seul noeud
recevant l’ensemble des requêtes des utilisateurs. Elle repose sur un ensemble
de noeuds gérant chacun une partie de ces requêtes. La répartition des requêtes
entre différents noeuds, voire entre différents réseaux Blockchain (cf. Chapitre 5),
permet d’augmenter la capacité du système de sécurité. Un passage à l’échelle im-
portant est donc garanti tant pour l’authentification [YSW+ 18], le contrôle d’accès
[PGDB17] que la préservation de l’anonymat [LWQL18] ;
— l’établissement de confiance : la Blockchain permet à des noeuds indépendants
d’échanger des informations de manière sécurisée, sans nécessiter l’intervention
d’un organe de contrôle central. Ainsi, même en l’absence de connectivité Inter-
net, la Blockchain pourrait permettre de vérifier la validité des messages transmis
par les usagers de la route [YCT+ 19, YSW+ 18]. La Blockchain représente donc
une solution pertinente pour l’établissement de confiance dans les réseaux véhi-
66
culaires.
Couplée au plan de connaissance (cf. Section 3.5.4.1), la Blockchain pourrait donc

permettre de répondre à l’ensemble des limites du plan de sécurité et de respect de
la vie privée. De plus, cette technologie pourrait être utilisée comme base du plan de
sécurité et de respect de la vie privée. En effet, elle permet de répondre aux besoins
des différents plans. Tout d’abord, à ceux du plan de gestion, par exemple, pour la
configuration et la migration des fonctions réseau [ARD18, RASD19]. Ensuite, à ceux
du plan de contrôle et de données, par exemple, pour le contrôle de la validité des
messages [LWQL18, SBN18]. Enfin, à ceux du plan de connaissance, notamment, pour
le contrôle d’accès [PGDB17].
Les travaux menés dans cette thèse portent sur la définition d’une approche logicielle
et sécurisée pour la distribution géographique des données dans l’IoV. La technologie
Blockchain sera étudiée dans le chapitre 5 de ce document.
Dans ce chapitre 5, en nous plaçant dans le contexte de réseaux véhiculaires définis
logiciellement, nous nous proposerons de :
— démontrer l’intérêt de la technologie Blockchain pour la sécurisation des échanges

entre les noeuds IoV (véhicules, équipements de bord de route, contrôleurs SDN) ;
— proposer et implémenter une architecture basée sur la Blockchain garantissant un
passage à l’échelle et un niveau de sécurité élevé ;
— définir et implémenter des mécanismes basées sur cette technologie pour l’authen-
tification, la révocation et le contrôle d’accès des noeuds IoV ;
— comparer les performances de la solution considérée par rapport aux solutions
proposées dans la littérature ;
— évaluer comment cette solution pourrait être déployée dans un environnement
réel en considérant le cas des États-Unis ;
Ainsi, cette technologie sera ici considérée pour la sécurisation du plan de contrôle
et de données de l’architecture de communication véhiculaire. Toutefois, comme in-
diqué dans la section 3.5.3, cette technologie pourrait également être appliquée à la
sécurisation du plan de gestion et du plan de connaissance.
67
3.5.4 Définition d’un plan de connaissance

Dans cette section, nous présentons les bénéfices qui pourraient résulter de la défini-
tion d’un plan de connaissance (cf. Section 3.5.4.1). Nous mettons également en avant
la façon dont ce plan sera abordé dans la suite de cette thèse (cf. Section 3.5.4.2).
3.5.4.1 Bénéfices
Comme cela a été expliqué dans la section 3.4.4, les approches considérées jusqu’ici
pour le traitement des données présentent différentes limites :
— le traitement des données n’a pas été considéré pour le plan de sécurité et de res-
pect de la vie privée. Or, cette approche pourrait présenter de nombreux bénéfices
pour ce plan (cf. Section 3.2.1) ;
— le traitement des données est réalisé de façon indépendante pour chaque plan.
Or, les traitement nécessaires pour ces différents plans peuvent s’appuyer sur de
mêmes informations : trajectoire du véhicule, qualité des liens de communication,
etc. Ce traitement indépendant entraîne donc une duplication de tâche et une
utilisation inutile de ressources ;
— le traitement des données est réalisé de façon indépendante pour chacune des
couches du plan de contrôle et de données. Or, certains protocoles sont multi-
couches (notamment SDN) et nécessitent un échange d’informations entre les dif-
férentes couches. Un traitement multi-couche doit donc être considéré.
Pour répondre à ces limitations, la définition d’un plan de connaissance apparaît

comme une solution pertinente. Cette idée de plan de connaissance, tout d’abord in-
troduite pour les réseaux autonomes mobiles [MdSNP08], a longtemps été confrontée
à des contraintes techniques [MALP11] : capacité de calcul, énergie, etc. Toutefois, les
avancées techniques récentes permettent d’envisager son déploiement, notamment pour
les architectures SDN distribuées [MRNC+ 17, MCK19b, ZWZ18].
Ce plan de connaissance (KP, Knowledge Plane) correspond à une base d’informa-
tions distribuée simplifiant le partage d’informations entre les différents plans et les
différentes couches de l’architecture C-ITS. Il s’agit notamment d’informations concer-
nant le contexte, les politiques de gestion et les évolutions de la topologie du réseau. Ce
plan de connaissance permet également la prise de décisions inter-couches (Facilities,
68
Networking and Transport) et inter-plans (plan de gestion, plan de contrôle et de don-

nées). Ceci est possible grâce à la définition de modèles de représentation des données,
à des pré-traitements et à des outils d’analyse des données et de prédiction.
Le fonctionnement de ce plan se base sur différents éléments (cf. Figure 3.5) :
— le module d’abstraction de source (Source Abstraction) : il permet de garan-
tir une récupération standardisée des données quelle que soit leur provenance :
capteurs physique, capteur virtuel, protocole, application, etc.
— la base d’informations liées à la connaissance (Knowledge Information Base) :
elle contient les informations remontées par le module d’abstraction des sources
et provenant des différents plans de l’architecture de référence C-ITS (gestion,
contrôle et données, sécurité et respect de la vie privée). En fonction de l’origine
des données (protocole, application, etc.) et de leur complexité, différents modèles
de stockage peuvent être considérés (document, objet, graphes, etc.) ;
— le module de traitement des données (Analyser) : il permet un traitement des
données qui simplifiera par la suite leur analyse et la prise de décisions : modi-
fication du format, élimination de redondances, synchronisation, concaténation,
etc. Ce module récupère en temps réel les données contenues dans la base d’in-
formations liées à la connaissance. Pour le traitement de données volumineuses,
ce module pourrait se baser sur les technologies de données massives décrites
précédemment (cf. Section 3.3.5.1) ;
— le module de prise de décisions (Decision-making Module) : il fournit une aide
à la prise de décision aux différents plans et des différents couches C-ITS. Ainsi,
leur fonctionnement pourra être optimisé. Pour des prises de décisions complexes,
ce module pourrait s’appuyer sur les techniques d’Intelligence Artificielle décrites
précédemment (cf. Section 3.3.5.1) ;
— les services du plan de connaissance (KP services) : ils correspondent à l’inter-
face de programmation (API) permettant aux autres plans de l’architecture C-ITS
de récupérer de façon standardisée les informations contenues dans le plan de
connaissance. Ce module expose par conséquent les différentes fonctionnalités of-
fertes par le plan de connaissance. Il adapte également le format des données
(XML, JSON, etc.) aux besoins des différents éléments C-ITS. Il est à noter que les
informations proviennent généralement du module de prise de décisions. Tou-
69
tefois, elle peuvent également provenir du module de traitement des données

(notification d’un évènement, remontée systématiques de certains types d’infor-
mations).
Ce plan de connaissance, couplé autres évolutions de l’architecture de référence C-

ITS (cf. Section 3.5.3.1, 3.5.2.1), pourrait offrir de nombreux bénéfices :
— pour le plan de gestion : ce plan de connaissance rendrait possible un dé-

ploiement optimal des applications et des tâches en fonction des conditions, par
exemple des ressources disponibles [SSZ+ 18]. Il pourrait également améliorer
l’orchestration des applications [GYHX18]. Ainsi, associé à la technologie NFV,
ce plan pourrait permettre de répondre à l’ensemble des limites identifiées pour le
plan de gestion (cf. Section 3.5.2.1) ;
— pour le plan de contrôle et de données : ce plan de connaissance pourrait tout

d’abord s’appliquer à la reconfiguration rapide du réseau, au travers d’une estima-
tion de la mobilité et des déplacements à venir des véhicules [LZZ+ 17]. Il pourrait
également améliorer l’interopérabilité et la gestion des handovers entre réseaux
hétérogènes [AA15]. Enfin, il assurerait une gestion optimale des ressources, no-
tamment de la bande passante [MEGBT16]. Ainsi, associé aux technologies SDN
et EC, ce plan pourrait permettre de répondre à l’ensemble des limites identifiées
pour le plan de contrôle et de données (cf. Section 3.5.2.1) ;
— au niveau du plan de sécurité et de respect de la vie privée : ce plan de connais-

sance pourrait tout d’abord s’appliquer à l’amélioration des fonctions de sécurité
existantes, notamment pour la détection d’intrusions [ZQML18]. Il pourrait éga-
lement rendre possible l’établissement de confiance, au travers du contrôle de la
validité des informations échangées entre les véhicules [KKZ18]. Enfin il pourrait
être utile pour le passage à l’échelle, notamment en considérant la technologie
Blockchain comme base de ce plan de sécurité et respect de la vie privée [DT18].
Ainsi, associé à la technologie Blockchain, ce plan pourrait permettre de répondre
à l’ensemble des limites identifiées pour le plan de sécurité et de respect de la vie
privée (cf. Section 3.5.3.1).
70
Les travaux menés dans le cadre de cette thèse portent sur la définition d’une ap-
proche logicielle et sécurisée pour la distribution géographique de données dans l’IoV.
Deux mécanismes, utilisés dans le chapitre 4, s’appuient sur un traitement intelligent
des données :
— la prédiction de la mobilité des véhicules au cours du temps (cf. Section 4.4.3).

Plus particulièrement, la solution proposée dans le chapitre 4 nécessite une prédic-
tion de la mobilité inter-cellules des véhicules en fonction de différents paramètres
(direction, vitesse, niveau de charge des stations de base) ;
— l’estimation, au cours du temps, du niveau de charge des équipements réseau

(cf. Section 4.4.4). Plus particulièrement, la solution proposée dans le chapitre 4
nécessite une prédiction du niveau de charge des stations de base en fonction de
différents paramètres (capacité, seuil maximal, prédiction de mobilité).
Comme nous l’avons indiqué dans la section 3.5.4.1, ce plan de connaissance pour-
rait être bénéfique pour l’architecture C-ITS dans son ensemble. Aussi, dans le cha-
pitre 4, une section sera consacrée à la présentation des bénéfices du plan de connais-
sance pour la distribution géographique des données (cf. Section 4.7.1). De même, dans
le chapitre 5, une section sera consacrée à la présentation des bénéfices du plan de
connaissance pour la sécurisation des communications (cf. Section 5.7.1). Une analyse
croisée de ces deux sections (4.7.1, 5.7.1) est proposée en annexe (cf. Annexe J .).
Cette analyse croisée présente les besoins de traitement communs aux différents plans
de l’architecture C-ITS et démontre ainsi l’intérêt d’un plan de connaissance global.
3.5.5 Résumé
Dans cette section, nous avons défini une nouvelle architecture de communication
pour les réseaux véhiculaires (cf. Figure 3.5). Celle ci doit permettre de répondre à l’en-
semble des limites de l’architecture de référence C-ITS (cf. Section 3.2.1). Pour ce faire,
elle repose sur trois améliorations principales. Tout d’abord, elle combine l’ensemble
des évolutions proposées dans la littérature (cf. Section 3.5.2, 3.5.2.2). Ensuite, elle uti-
lise la technologie Blockchain pour améliorer les performances du plan de sécurité et
de respect de la vie privée (cf. Sections 3.5.3.1, 3.5.3.2). Enfin, elle intègre un plan de
connaissance au service de l’ensemble de l’architecture (cf. Sections 3.5.4.1, 3.5.4.2).
71
3.6 Conclusion
Dans ce chapitre, nous avons introduit notre première contribution : une évolution
de l’architecture de référence C-ITS devant permettre l’avènement de l’IoV (cf. Section
2.4.2).
Pour ce faire, nous avons commencé par identifier les principales limites de l’archi-
tecture de référence C-ITS (cf. Section 3.2.1). Celles ci peuvent être liées à la gestion
(déploiement, cycle de vie des applications, etc.), au contrôle (interopérabilité, reconfi-
guration, etc.), à la sécurité et au respect de la vie privée (confiance, passage à l’échelle,
etc.) ou globales (traitement des données).
Dans un second temps, nous avons présenté des solutions technologiques qui pour-
raient permettre de répondre à ces limitations : SDN (cf. Section 3.3.1.1), NFV (cf. Sec-
tion 3.3.2.1), l’EC (cf. Section 3.3.3.1), la Blockchain (cf. Section 3.3.4.1) et les données
massives et l’intelligence artificielle (cf. Section 3.3.5.1).
Dans un troisième temps, nous avons listé les évolutions proposées dans la littérature
pour l’amélioration de la gestion (cf. Section 3.4.1), du contrôle (cf. Section 3.4.3) et
de la sécurité (cf. Section 3.4.3) de l’architecture C-ITS. Nous avons également mis en
avant les principales limites de ces travaux (cf. Section 3.4.4) : la non considération du
plan de sécurité et de respect de la vie privée et un traitement insuffisant des données.
Afin d’y répondre, nous avons finalement proposé une nouvelle architecture de com-
munication. La solution proposée combine les bénéfices des approches existantes (cf.
Section 3.5.2). De plus, elle définit un plan de connaissance (cf. Section 3.5.4) permet-
tant un traitement efficace et intelligent des données. Enfin, elle introduit la technologie
Blockchain dans le plan de sécurité et de vie privé, garantissant un niveau de sécurité et
de passage à l’échelle plus élevé (cf. Section 3.5.3). Ainsi, l’architecture proposée, évo-
lution de l’architecture de référence C-ITS, pourrait permettre de répondre à l’ensemble
des besoins de l’IoV et des applications C-ITS.
Dans le chapitre suivant, nous nous focaliserons sur un point essentiel dans l’envi-
ronnement véhiculaire : la distribution géographique de données. Pour y répondre nous
développerons une solution basée sur une des technologies que nous proposons d’inté-
grer dans l’architecture de référence : SDN. Nous mettrons également en avant l’intérêt
du plan de connaissance dans ce contexte.
72
Chapitre 4
Une approche logicielle performante

pour la distribution géographique des
données
4.1 Introduction
Le fonctionnement de nombreuses applications C-ITS repose sur un échange effi-
cace des données entre les équipements terminaux situés dans une même zone géo-
graphique (cf. Section 2.3.2.2). Cette diffusion locale de données s’appuie, avant tout,
sur des communications directes entre équipements terminaux (V2V, V2P). En effet, ces
communications objet-à-objet permettent de garantir une latence extrêmement faible.
Néanmoins, certaines applications C-ITS nécessitent la diffusion d’informations dans
des zones géographiques plus vastes. Ces zones peuvent aller de plusieurs centaines de
mètres à plusieurs kilomètres (cf. Tableau 2.2). Dans ce contexte, les communications
directes objet-à-objet pourraient offrir une solution peu fiable : rupture de connectivité,
perte de paquets, etc.
L’utilisation de l’infrastructure de bord de route (V2I, I2I, V2N) apparaît comme une
alternative intéressante pour cette diffusion à plus large échelle. Les réseaux cellulaires,
intégrés dans l’architecture IoV et largement déployés (cf. Section 2.3.3.2), apparaissent
notamment comme une solution pertinente. Ils pourraient, en effet, garantir une distri-
bution géographique fiable et des performances acceptables (latence, bande passante,
perte de paquets).
Toutefois, le protocole GeoNet (cf. Section 2.3.3.1), actuellement considéré pour la
distribution géographique des données, est peu adapté à une distribution des données
via l’infrastructure de bord de route. En effet, lorsque la distribution géographique des
données s’appuie sur l’infrastructure réseau, ce protocole s’avère peu flexible et coûteux
en ressources (cf. Section 4.2.1).
73
4. Une approche logicielle performante pour la distribution géographique des données
C’est pourquoi, dans ce chapitre, nous introduisons notre seconde contribution. La

solution que nous proposons vise à garantir une gestion performante de l’infrastructure
cellulaire pour la distribution géographique des données véhiculaires. Cette contribu-
tion s’appuie sur une technologie dont nous avons proposé l’intégration dans l’architec-
ture de référence C-ITS : SDN (cf. Section 3.3.1.1).
Dans ce chapitre, nous commençons par justifier l’intérêt d’utiliser une approche lo-
gicielle pour distribuer géographiquement des données (cf. Section 4.2.1). Nous présen-
tons, ensuite, les travaux ayant déjà proposé une approche logicielle pour la distribution
géographique de données (cf. Section 4.3) et identifions leurs limites (cf. Section 4.3.5).
Puis, nous définissons le contexte considéré dans ce chapitre (cf. Section 4.4). Dans un
quatrième temps, nous présentons une nouvelle approche logicielle pour la distribution
géographique des données (cf. Section 4.5). Celle-ci s’appuie notamment sur une utili-
sation optimale des ressources à disposition : bande passante, table des flux, canal de
contrôle, etc. Les bénéfices de cette approche sont, par la suite, démontrés (cf. Section
4.6). Pour finir, nous discutons de l’intérêt que pourrait présenter le plan de connais-
sance de l’architecture de communication C-ITS (cf. Section 3.5.4.1) dans ce contexte
(cf. Section 4.7.1).
4.2 Motivations
4.2.1 Présentation
Le fonctionnement de nombreuses applications C-ITS repose sur une dissémination
efficace de données entre équipements terminaux situés dans une même zone géogra-
phique. Ceci est notamment vrai pour les applications de prévention coopérative de
collisions, de création coopérative de cartes HD, de gestion de places de parking ou de
téléchargement coopératif de médias (cf. Section 2.3.2.2).
Les communications V2I, V2N, I2I, garantissant une stabilité élevée, sont utilisées
pour distribuer les données dans des zones géographiques étendues. Ces zones peuvent
aller de plusieurs centaines de mètres à plusieurs kilomètres (cf. Tableau 2.2). L’utilisa-
tion du réseau cellulaire apparaît notamment comme pertinente. En effet, les stations
de base sont déployées en grand nombre. De plus, les communications cellulaires sont
intégrées dans l’architecture de référence C-ITS (cf. Section 2.3.4). Enfin, les communi-
cations cellulaires garantissent des performances acceptables : bande passante, latence,
74
perte de paquets.
La distribution géographique des données entre terminaux mobiles (V2V, V2P), ou
via l’infrastructure (V2N), s’appuie sur un protocole C-ITS dédié : GeoNet (cf. Section
2.3.3.1) [SSCU16]. Ce protocole offre une solution efficace pour la diffusion de données
au travers de communications directes entre équipements terminaux (V2V, V2P). En
effet, il limite les risques de "tempête de diffusion" (broadcast storm). De plus, il supporte
différents types de communication : unicast, broadcast, anycast. Enfin, il garantit des
délais de transmission courts.
En revanche, le protocole GeoNet apparaît moins performant lorsqu’il est utilisé pour
une distribution des données via l’infrastructure cellulaire 1 (cf. Annexe E .). En effet, il
présente différentes limites, notamment :
— un traitement inefficace des informations : lorsqu’un équipement terminal en-
voie une information à une station de base, celle-ci la transmet au centre de
contrôle (cf. Figure 7.3). Ce centre de contrôle traite individuellement chacune
des informations qu’il reçoit. Il détermine, tout d’abord, en fonction de l’adresse de
destination, la zone géographique dans laquelle l’information doit être transmise.
Il la transmet ensuite aux stations de base appartenant à cette zone géographique.
Ce traitement et cette distribution individuels des informations entraînent une
utilisation inefficace de ressources au niveau du centre de contrôle et du réseau
(calcul, bande passante) [LCC15]. De plus, cette solution induit nécessairement
une latence importante. Aussi, la définition d’une solution permettant un traite-
ment et une diffusion plus efficace des informations apparaît comme nécessaire ;
— une distribution statique des informations : lorsque le centre de contrôle reçoit
une information, il la transmet a l’ensemble des stations de base situées dans la
zone géographique de destination (broadcast). Or, ces stations de base sont utili-
sées par l’ensemble des applications utilisant les réseaux cellulaires : multimédia,
VoIP, etc. Par conséquent, les ressources à disposition (bande passante, chemins
dee communication) doivent être utilisées efficacement. Sans cela, le bon fonc-
tionnement de l’ensemble des applications ne pourra être garanti. Or, certaines ap-
plications C-ITS pourraient entraîner une augmentation significative de la charge
du réseau (cartes HD, téléchargement coopératif). Une distribution des données à
1. "Observations on GeoNetworking", EU-US ITS Task Force Standards Harmonization Working Group
Harmonization Task Groups 1 and 3, Version : 2012-11-12
75
l’ensemble des stations de base situées dans la zone géographique de destination,

sans prendre en compte la position des destinataires, semble donc peu efficace.
De plus, la zone de distribution de certaines applications C-ITS est caractérisée
par une taille minimale et donc variable (cf. Section 2.3.2.2). Aussi, les stations
de base destinataires pourraient être sélectionnées en fonction de la position des
équipements terminaux destinataires et du niveau de charge de ces stations de
base. Cette approche dynamique pourrait permettre de garantir des performances
élevées.
Ainsi, le protocole GeoNet présente des limites importantes lorsque l’infrastructure

de bord de route est utilisée pour la diffusion géographique des données. Par consé-
quent, la définition d’une nouvelle solution apparaît comme essentielle pour garantir
une utilisation efficace des ressources à disposition et des performances élevées (la-
tence, bande passante).
Pour définir cette solution, une technologie dont nous avons proposé l’intégration
dans l’architecture de référence C-ITS pourrait s’avérer pertinente : SDN (cf. Section
3.3.1.1). En effet, l’approche SDN, avec le protocole OpenFlow (cf. Annexe G .), per-
met de programmer les équipements réseau. Ainsi, des règles de flux assurant une dis-
tribution géographique automatique des données pourraient être dynamiquement dé-
ployées. Lorsqu’une station de base recevrait une information, elle pourrait être en me-
sure d’associer l’adresse géographique 2 à une entrée dans la table des flux. Elle pourrait
donc la transmettre à l’ensemble des stations de base de destination sans intervention
d’un contrôleur ou d’un centre de contrôle. La programmabilité des équipements réseau
offre donc une réponse à la problématique de traitement inefficace des informations. De
même, la vision centrale du plan de contrôle SDN pourrait permettre de garantir une
distribution dynamique des données (multicast). En effet, les règles de flux pourraient
être modifiées en fonction de l’état réel du réseau. Ceci garantirait donc une réactivité
importante et une utilisation optimale des ressources à disposition.
L’utilisation de la technologie SDN pour la distribution géographique des données
pourrait donc permettre de répondre aux limites du protocole GeoNet. Néanmoins, les
réseaux d’accès cellulaires sont hautement mobiles. Or, le déploiement d’une solution
basée sur SDN dans un environnement mobile nécessite une attention particulière. Il
1026360401v010101p.pdf
76
est notamment nécessaire de :
— limiter le nombre d’échanges entre le plan de contrôle et les équipements

réseau : le plan de contrôle SDN, qu’il soit centralisé ou distribué (cf. Section
3.3.1.1), est en charge de la gestion de la mobilité des équipements terminaux.
Par conséquent, à chaque déplacement d’un équipement terminal (d’une cellule
réseau vers une autre), le plan de contrôle doit déployer des règles de flux permet-
tant d’assurer la continuité des communications (cf. Annexe F .). Or, une approche
réactive, dans laquelle le contrôleur attendrait de recevoir une requête (Packet In)
pour déployer des règles de flux adaptées [KDDP18], pourrait avoir deux consé-
quences majeures. Tout d’abord, une inévitable latence liée aux échanges entre
l’équipement réseau et le contrôleur SDN. Ensuite, une augmentation de la charge
du canal de contrôle. Cette latence et cette augmentation de la charge du canal de
contrôle pourraient avoir une même conséquence : une dégradation des perfor-
mances [KD17]. Aussi, pour garantir des performances élevées, limiter le nombre
d’échanges entre le plan de contrôle et les équipements réseau semble essentiel ;
— limiter le taux d’occupation des tables de flux : l’accès rapide au contenu des
tables de flux est permis par l’utilisation d’un type de mémoire particulier : une
mémoire ternaire adressable par le contenu (TCAM, Ternary Content Addressable
Memory) [WYC+ 16]. Cette mémoire présente un inconvénient majeur : son coût.
Par conséquent, pour garantir des coûts de déploiement acceptables, la taille des
tables de flux déployées au niveau des équipements réseau (et notamment des
stations de base) sera nécessairement limitée. Or, un environnement mobile im-
plique l’ajout fréquent de règles de flux. Les règles de flux inutiles, correspondant
à une position passée d’un équipement terminal, doivent donc être supprimées
de façon efficace [CWWL18]. Sans cela, les tables de flux pourraient se retrouver
surchargées. Dans ce cas de figure, il deviendrait impossible d’ajouter de nouvelles
règles à ces tables. Ainsi, la gestion d’un nouveau paquet entraînerait l’envoi sys-
tématique d’une requête Packet In au contrôleur SDN et donc une augmentation
importante de la charge du canal de contrôle. Aussi, pour garantir des perfor-
mances élevées, il semble essentiel de limiter le taux d’occupation des tables de
flux.
Dans la définition d’une approche basée sur SDN, il parait donc nécessaire de
77
prendre en compte le taux d’occupation des tables de flux et le nombre d’échanges

entre contrôleurs SDN et équipements réseau.
C’est pourquoi, dans ce chapitre, notre objectif est double. Il s’agit, tout d’abord,
d’utiliser l’approche SDN pour gérer la distribution géographique des données (traite-
ment efficace des informations, distribution dynamique). Il s’agit, ensuite, de proposer
une solution pouvant garantir l’efficacité de la technologie SDN dans cet environnement
mobile (limitation des échanges, limitation du taux d’occupation des tables de flux).
Pour ce faire, nous commençons par présenter les solutions existantes (cf. Section
4.3). Nous identifions, également, les principales limites de ces travaux (cf. Section
4.3.5). Par la suite, partant des axes d’amélioration identifiés, nous proposons une nou-
velle solution pour une distribution géographique des données basée sur la technologie
SDN (cf. Section 4.5). Notre approche s’appuie, notamment, sur la définition de ma-
chines d’état et sur une prise en compte du niveau de charge des équipements réseau.
Son évaluation tend à démontrer ses bénéfices par rapport à l’existant (cf. Section 4.6).
Enfin, considérant l’architecture de communication C-ITS dans sa globalité, nous ex-
pliquons l’intérêt du plan de connaissance (cf. Section 3.5.4.1) dans ce contexte (cf.
Section 4.7.1).
4.2.2 Résumé
Notre objectif est d’offrir une distribution géographique des données efficace via
l’infrastructure cellulaire. Aussi, dans cette section, nous commençons par identifier
les principales limites du protocole actuellement utilisé pour cette distribution géogra-
phique : GeoNet (cf. Section 2.3.3.1). Cette solution ne permet notamment pas de gérer
et de distribuer efficacement ces données géographiques. Nous introduisons, ensuite,
une technologie qui, grâce à sa dynamicité et sa vision centralisée du réseau, pourrait
permettre de répondre à ces limitations : SDN. Enfin, nous ciblons deux éléments devant
être considérés pour que la technologie SDN puisse être efficacement déployée dans un
environnement mobile. Il est, en effet, nécessaire de limiter le nombre d’échanges entre
le plan de contrôle et les équipements réseau et de réduire le taux d’occupation des
tables de flux.
78
4.3 Solutions existantes

Ce chapitre s’intéresse à la distribution géographique des données C-ITS. Plus par-
ticulièrement, l’objectif est de proposer une approche logicielle permettant d’utiliser
efficacement l’infrastructure cellulaire dans le cadre de cette distribution.
Pour y parvenir, quatre éléments essentiels, liés aux limites du protocole GeoNet et à
la gestion de la mobilité avec SDN, doivent être pris en compte (cf. Section 4.2.1). Aussi,
dans cette section nous présentons les améliorations proposées dans la littérature pour
le traitement (cf. Section 4.3.1) et la distribution des informations (cf. Section 4.3.2)
ainsi que la limitation des échanges entre le plan de contrôle et les équipements réseau
(cf. Section 4.3.3) et la gestion des table de flux (cf. Section 4.3.4). Nous proposons
également une comparaison des solutions existantes et mettons en avant les points qui
devraient encore être considérés (cf. Section 4.3.5).
4.3.1 Traitement des données

Le protocole GeoNet nécessite la redirection de l’ensemble des messages vers un
centre de contrôle (cf. Annexe E .). En fonction de l’adresse géographique de destina-
tion, ce centre de contrôle se charge, ensuite, de distribuer individuellement chaque
message. Cette approche implique donc une consommation importante de ressources
(calcul, bande passante) ainsi qu’une latence liée aux délais nécessaires pour gérer
chaque message.
L’approche SDN semble, par nature, offrir une réponse à cette limite identifiée pour
le protocole GeoNet. En effet, la technologie SDN permet au plan de contrôle de dé-
ployer dynamiquement des règles de flux au niveau des équipements réseau (cf. An-
nexe G .). Par conséquent, il est possible de déployer des règles de flux correspondant
à chacune des zones de distribution géographiques. Ainsi, avec la technologie SDN,
les stations de base sont en mesure de gérer de manière autonome les informations
transmises par les véhicules. En fonction de l’adresse de destination, elles transmettent
directement les données aux stations de base destinataires, sans intervention du centre
de contrôle ni du contrôleur SDN.
Différents travaux, à l’image de [dSdCS+ 18, LCC15, SNL18], se sont déjà intéressés
à un traitement des données géographiques basé sur une approche logicielle et non
sur un centre de contrôle. Ils ont, notamment, démontré qu’une approche basée sur la
79
technologie SDN pourrait permettre des gains de près de 50% en terme de latence et
de près de 60% en terme d’utilisation de la bande passante. Ils ont, également, mis en
avant le fait que l’élimination du centre de contrôle pourrait permettre de réduire de
près de 80% le surcoût lié au contrôle de la distribution géographique.
Ainsi, l’approche SDN, limitant les interventions du centre de contrôle, permet de
garantir de meilleurs performances en terme de traitement des données.
4.3.2 Distribution des données

La principale limite du protocole GeoNet pour la distribution des données réside
dans la non flexibilité de l’approche adoptée. Les données sont transmises systémati-
quement à l’ensemble des stations de base situées dans une zone géographique donnée
(broadcast). La présence ou non de destinataires connectés à ces stations de base n’est
pas prise en compte. De même, le niveau de charge de ces stations de base n’est pas
considéré alors que pour certaines applications C-ITS la zone de distribution pourrait
être de dimensions variables (cf. Section 2.3.2.2). Aussi, le protocole GeoNet pourrait
entraîner une augmentation inutile de la charge du réseau et une dégradation des per-
formances.
C’est pourquoi différents travaux ont déjà étudié la possibilité de définir une ap-
proche logicielle pour distribuer géographiquement des données [XWL15, DKS+ 18,
KS19]. Ces travaux se sont plus particulièrement concentrés sur l’idée de sélectionner
les stations de base destinataires en fonction de la position des véhicules (multicast).
Ainsi, utilisant les informations remontées par les stations de base, le contrôleur SDN
détermine où se trouvent actuellement les véhicules et quelles stations de base doivent
être desservies. Il construit, ensuite, un arbre multicast garantissant une diffusion effi-
cace des données. Enfin, il déploie les règles de flux permettant d’assurer ces communi-
cations au niveau des équipements réseau.
En fonction de l’objectif de la solution, efficacité énergétique [KS19] ou latence mi-
nimale [XWL15, DKS+ 18], différents procédés ont été considérés pour la construction
des arbres de multicast. Néanmoins, l’ensemble de ces travaux ont démontré que l’uti-
lisation d’une approche logicielle pourrait permettre une amélioration significative des
performances. Une utilisation plus efficace de la bande passante et une réduction de
la latence et du taux de perte de paquets ont ainsi pu être mesurés. Ces avantages
sont notamment permis par la vision centralisée du contrôleur SDN et le déploiement
80
dynamique de règles de flux.
4.3.3 Échanges entre plan de contrôle et équipements réseau

La technologie SDN pourrait permettre d’améliorer la distribution géographique des
données (cf. Section 4.2.1). Toutefois,l’utilisation de la technologie SDN dans un envi-
ronnement mobile nécessite de porter une attention particulière aux échanges entre les
contrôleurs SDN et les équipements réseau.
Le contrôleur SDN est responsable de la mobilité des équipements terminaux. Or,
une gestion réactive de cette mobilité pourrait entraîner un surcoût important. En effet,
à chaque déplacement d’un véhicule entre deux stations de base, une requête Packet In
serait envoyée au contrôleur SDN (cf. Annexe F .). Ce mode de fonctionnement impli-
querait inévitablement une latence liée à la définition et au déploiement de nouvelles
règles de flux par le contrôleur SDN. Il pourrait, également, résulter en une augmenta-
tion de la charge du canal de contrôle. Ceci pourrait entraîner un dysfonctionnement
du plan de contrôle [KD17].
Aussi, de nombreux travaux, portant sur la technologie SDN, se sont intéressés à la
gestion pro-active de la mobilité des équipements terminaux. Cette gestion pro-active
de la mobilité s’appuie systématiquement sur l’utilisation de modèles de prédiction de
mobilité [ZD18] (cf. Section 4.4.3). Toutefois, ces modèles de mobilité peuvent être
utilisés de différentes manières.
Une première approche [BMO16, AMS20] consiste à pré-calculer des règles de flux
en fonction de la prédiction de mobilité des équipements terminaux. Ainsi, pour chaque
équipement terminal, l’outil de prédiction de mobilité calcule les positions à venir et le
contrôleur SDN détermine les règles de flux qui seront nécessaires. Cette approche per-
met de diminuer le temps de réponse du contrôleur SDN [BMO16]. En effet, les règles
de flux ayant déjà été pré-calculées, lorsqu’un contrôleur SDN reçoit une requête Packe-
tIn, il a simplement à déployer ces règles au niveau des équipements réseau. Néanmoins,
cette approche ne permet pas de réduire le nombre de requêtes PacketIn envoyées au
contrôleur SDN. En effet, les règles ne sont déployées qu’en réponse à une requête.
Aussi, avec cette approche, une surcharge du canal de contrôle est toujours possible.
C’est pourquoi une seconde solution consiste à pré-calculer et pré-déployer les règles
de flux permettant d’assurer la continuité des communications [BMO18, RASM17,
DLOX15, KR15]. Ainsi, dans ces travaux, pour chaque équipement terminal, l’outil de
81
prédiction de mobilité calcule, tout d’abord, les positions à venir. Puis, le contrôleur
SDN détermine les règles de flux qui seront nécessaires et les pré-déploie au niveau des
équipements réseau (routeurs, stations de base). Grâce à cette approche, la continuité
des communications peut généralement être assurée, sans intervention du contrôleur
SDN (cf. Annexe F .). En effet, les règles de flux étant déjà déployées, la station de
base peut gérer les communications de l’équipement terminal sans envoyer de requêtes
Packet In. Ainsi, cette approche permet de limiter l’utilisation du canal de contrôle.
4.3.4 Gestion des tables de flux
L’utilisation de la technologie SDN dans un environnement mobile nécessite égale-

ment une gestion efficace des tables de flux.
Considérant l’utilisation d’une mémoire TCAM, coûteuse [WYC+ 16], le nombre d’en-
trées dans la table des flux des équipements réseau sera nécessairement limité. Or, il est
essentiel d’éviter que ces tables de flux ne soient surchargées. En effet, lorsqu’une table
de flux est pleine, si un équipement réseau a un nouveau flux de données à gérer, il
devra systématiquement envoyer une requête au contrôleur SDN. Ceci pourrait donc
entraîner une surcharge du canal de contrôle et une latence dans les communications.
Dans l’environnement véhiculaire, cette gestion de la table des flux consiste, notam-
ment, à gérer la durée de vie des règles de flux (cf. Annexe G .). En effet, les équipe-
ments terminaux sont mobiles. Par conséquent, il est nécessaire que les règles de flux
correspondant à la position passée d’un équipement terminal soient automatiquement
supprimées. Celles-ci ne sont plus nécessaires et occupent inutilement une entrée dans
une ou plusieurs tables de flux.
C’est pourquoi différents travaux se sont intéressés à la définition dynamique de la

durée de vie des règles de flux [BMO16, BMO18, DLOX15]. Ces travaux se basent tous
sur une même idée : utiliser les informations concernant la mobilité des véhicules pour
estimer la durée de vie des règles de flux. Connaissant le rayon de communication des
équipements de bord de route, la vitesse et la position des véhicules, il est possible
d’estimer la durée de vie des règles des flux. Ainsi, ce calcul dynamique de la durée de
vie des règles de flux assure une diminution du niveau de charge des tables de flux.
82
4.3.5 Comparaison
Ainsi, de nombreux travaux se sont intéressés à l’utilisation d’une approche logicielle
pour une distribution géographique des données via l’infrastructure cellulaire.
A l’image de [dSdCS+ 18, LCC15, SNL18, XWL15, DKS+ 18, KS19], plusieurs auteurs
ont démontré que l’utilisation de la technologie SDN pourrait permettre de surmonter
les limites actuelles du protocole GeoNet (cf. Section 4.2.1). Une approche logicielle
permettrait, avant tout, de garantir un traitement efficace des données, éliminant le
surcoût associé au centre de contrôle (cf. Section 4.3.1). De plus, la technologie SDN
pourrait garantir des performances plus élevées (perte de paquets, latence) ainsi qu’une
meilleure utilisation des ressources à disposition (cf. Section 4.3.2).
De même, différents travaux ont proposé des solutions permettant d’adapter la
technologie SDN à l’environnement véhiculaire [BMO16, AMS20, BMO18, RASM17,
DLOX15, KR15]. Ainsi, les solutions déjà introduites dans la littérature pourraient per-
mettre une limitation des échanges entre contrôleur SDN et équipements réseau (cf.
Section 4.3.3). Elles pourraient également rendre possible une meilleure gestion des
tables de flux (cf. Section 4.3.4).
Tableau 4.1 – Comparaison des travaux proposant une approche logicielle pour la dis-
tribution de données dans l’environnement véhiculaire
Approches Traitement Distribution Canal de contrôle Table des flux

[dSdCS+ 18, LCC15]
Oui Non Non Non
[SNL18]
[XWL15, DKS+ 18]
Oui Partiel Non Non
[KS19]
Non adaptatif
[BMO16, AMS20] Non Non Imprécis
(Pré-calcul)
[BMO18, RASM17] Non adaptatif
Non Non Imprécis
[DLOX15, KR15] (Pré-déploiement)
Proposition Oui Oui Oui Oui
Toutefois, comme le montre le tableau 4.1, aucun des travaux proposés jusqu’ici ne
s’intéresse conjointement aux questions de distribution géographique des données et
d’adaptation de la technologie SDN à l’environnement véhiculaire. De plus, même en
considérant une solution combinant les travaux existants, on peut identifier plusieurs
83
limites importantes :
— la non considération du niveau de charge des stations de base dans le processus

de distribution des données : les travaux existants (cf. Section 4.3.2) prennent
en compte la position des véhicules mais pas le niveau de charge des stations
de base destinataires. Or, un niveau de charge trop élevé pour ces stations de
base pourrait entraîner une dégradation des performances pour les applications
C-ITS. Pour certaines applications C-ITS, la zone de distribution géographique est
caractérisée par une dimension minimale et donc variable (cf. Section 2.3.2.2)
Ainsi, l’idée de gérer dynamiquement les dimensions des zones de distribution
géographiques pourrait être considérée. Ceci pourrait permettre de garantir un
niveau de charge acceptable pour les stations de base ;
— l’imprécision dans l’estimation de la durée de vie des règles de flux : dans les
approches existantes (cf. Section 4.3.4), le calcul de la durée de vie des règles de
flux se base uniquement sur la mobilité des véhicules. Or, le niveau de charge des
stations de base impacte nécessairement la gestion du handover des équipements
terminaux [GL17] (cf. Annexe F .). Par conséquent, la durée de connexion entre
un véhicule et une station de base dépendra directement du niveau de charge
de cette station de base et des stations de base environnantes. Ainsi, la prise en
compte du niveau de charge des stations de base dans l’estimation de la durée de
vie des règles de flux parait essentielle. Sans cela, la précision de cette estimation
ne pourra être garantie et les tables de flux ne pourront être gérées de façon
optimale ;
— le manque de flexibilité dans la gestion de la mobilité : les solutions de pré-

déploiement existantes ne se basent que sur des paramètres temporels (cf. Section
4.3.3). La durée de vie des règles de flux est notamment utilisée pour gérer la mo-
bilité des véhicules. Ainsi, lorsqu’une règle de flux est retirée de la table des flux
(Hard Timeout, cf. Annexe G .), les équipements réseau routent les informations
en fonction des règles pré-déployées qui correspondent à la nouvelle position du
véhicule. Toutefois, l’estimation de la durée de connexion entre un véhicule et
une station de base est nécessairement imprécise. Par conséquent, le moment du
handover ne correspondra pas exactement au moment de transition entre deux
règles de flux. Dans ce cas, le pré-déploiement des règles de flux s’avérera inutile.
84
En effet, toute différence entre le moment réel du handover et le moment estimé

entraînera l’envoi d’une requête Packet In au contrôleur SDN (cf. Annexe F .).
Par conséquent, il semble essentiel de ne pas uniquement prendre en compte des
paramètres temporels dans la gestion de la mobilité des véhicules.
Aussi, pour offrir une approche logicielle garantissant une distribution géographique
des données performante, la définition d’une nouvelle solution est essentielle. Une ges-
tion efficace de la mobilité (table des flux, échanges) et une utilisation optimale des res-
sources (niveaux de charge) doivent être considérées. C’est pourquoi, dans la suite de
ce chapitre, de nouveaux mécanismes sont introduits. Ceux-ci permettent notamment
l’estimation précise de la mobilité des véhicules (cf. Section 4.5.3.1), la prise en compte
du niveau de charge des stations de base (cf. Section 4.5.3.2), la définition de machines
d’état (cf. Section 4.5.4) et l’application d’une politique de pré-déploiement des règles
de flux (cf. Section 4.5.5). L’évaluation de la solution proposée tend à démontrer ses
avantages comparé aux approches existantes (cf. Section 4.6).
4.3.6 Résumé
Dans cette section, nous avons listés les travaux portant sur les limitations identifiées
dans la section 4.2.1. Les questions de traitement (cf. Section 4.3.1) et de distribution
des données (cf. Section 4.3.2) de gestion du canal de contrôle (cf. Section 4.3.3) et
de gestion des tables de flux (cf. Section 4.3.4) ont ainsi été étudiées. Dans un second
temps, nous avons comparé ces solutions et identifié leurs limites (cf. Section 4.3.5). Il
s’agit, notamment, de la non considération du niveau de charge des stations de base,
d’une estimation imprécise de la durée de vie des règles de flux et du manque de flexi-
bilité dans la gestion de la mobilité.
4.4 Contexte
Dans ce chapitre, nous utilisons une approche logicielle pour distribuer efficacement
les données géographiques via l’infrastructure cellulaire. Aussi, dans cette section, nous
définissons l’environnement cellulaire (cf. Section 4.4.1) et le scénario considérés (cf.
Section 4.4.2). Nous présentons, également, deux outils nécessaires au déploiement de
la solution considérée : un modèle de prédiction de mobilité (cf. Section 4.4.3) et une
méthode d’estimation du niveau de charge des stations de base (cf. Section 4.4.4).
85
4.4.1 Environnement
La solution proposée se base sur l’utilisation de réseaux cellulaires pour la distribu-

tion de données via l’infrastructure de bord de route. En effet, les réseaux cellulaires
sont largement déployés et offrent des performances acceptables (cf. Section 4.2.1).
Plus particulièrement, nous nous sommes positionnés dans le contexte des réseaux
cellulaires de 5ème génération. En comparaison avec les réseaux cellulaires 4G, les bé-
néfices des réseaux cellulaires 5G sont nombreux : densité plus élevée, bande passante
plus importante, latence réduite, meilleure utilisation du spectre et du réseau. De plus,
ces réseaux cellulaires 5G visent à supporter plusieurs types de communications, dont
les communications URLLC (Ultra Reliable Low Latency Communications), notamment
destinées aux communications véhiculaires. Enfin, l’intégration de ces réseaux cellu-
laires 5G dans l’architecture de référence C-ITS est prévue (cf. Section 2.3.4). Aussi, les
réseaux cellulaires 5G constituent une base pertinente pour le déploiement de solutions
destinées aux communications véhiculaires et basées sur l’infrastructure cellulaire.
Le fonctionnement de ces réseaux cellulaires 5G repose, entre autres, sur le déploie-
ment d’un nombre important de stations de base à faible rayon de communication : les
small cells [ANLC16]. Ces petites cellules rendront possible l’utilisation d’ondes milli-
métriques à haute fréquences pour les communications cellulaires. De plus, elles per-
mettront de supporter une densité importante de communications à débit élevé. Néan-
moins, le déploiement de cellules à faible rayon implique une gestion efficace des tran-
sitions entre cellules (cf. Annexe F .).
Ces réseaux cellulaires 5G, devraient, également, s’appuyer sur une technologie par-
ticulière : SDN (cf. Section 3.3.1.1). Ainsi, chaque équipement réseau serait défini lo-
giciellement et fournirait des informations au plan de contrôle SDN : délais, bande
passante, etc. Le plan de contrôle pourrait donc être en mesure d’assurer une gestion
efficace des ressources réseau à disposition, du contrôle de congestion et de la mobi-
lité des utilisateurs [BSAR15]. De plus, une Qualité de Service (latence, débit, perte
de paquets) suffisante pour les différentes applications (mMTC, eMBB, URLLC) et les
utilisateurs du réseau cellulaire pourrait être garantie.
Dans un environnement 5G défini logiciellement, pour supporter un passage à
l’échelle important, le plan de contrôle SDN est distribué (cf. Figure 4.1). Ainsi, un
ensemble de contrôleurs SDN, inter-connectés, sont en charge du contrôle du réseau.
86
F IGURE 4.1 – Représentation des réseaux 5G définis logiciellement
Chaque contrôleur SDN gère une zone géographique spécifique, correspondant à un

ensemble d’équipements réseau (routeurs, stations de base, équipements terminaux).
Des communications entre des zones géographiques gérées par différents contrôleurs
SDN sont rendues possibles grâce aux communications inter-contrôleurs (cf. Section
3.3.1.2). Ainsi, un fonctionnement global du réseau est garanti.
Dans ces réseaux cellulaires définis logiciellement, les fonctions du coeur du réseau
de communication (Core Network) 5G sont déployées sous formes d’applications SDN
virtuelles. On parle, notamment, de vSMF (virtual Session Management Function), vUPF
(virtual User Plane Function) et vAMF (virtual Access and Mobility Management Function)
[PTSD18]. Le fonctionnement du coeur du réseau 5G repose donc sur des échanges
entre équipements réseau, contrôleurs SDN et applications SDN : vSMF, vAMF, vUPF,
etc. Le contrôleur SDN fournit aux fonctions du coeur de réseau un ensemble d’infor-
mations (connexion/déconnexion, état des équipements réseaux, etc.) sur lesquelles se
basent les prises de décision des fonctions du coeur de réseau. Le contrôleur est ensuite
en charge de convertir les requêtes de ces applications en règles de flux.
87
4.4.2 Scénario de distribution géographique

Le scénario considéré pour la distribution géographique de données via l’infrastruc-
ture cellulaire est présenté en figure 4.2. Les caractéristiques de ce scénario sont les
suivantes :
— à l’image de BS C, chaque station de base a pour rôle de distribuer géographique-
ment les données générées par les véhicules qui y sont connectés (V2, V3) ;
— cette distribution géographique doit être effectuée dans une zone géographique
donnée. Une zone géographique correspond à un ensemble de stations de base
situées à proximité de BS C, ici, BS A, BS B, BS D, BS E ;
— une adresse géographique (GeoNet), convertie en adresse IPV6, correspond à une
zone géographique donnée [IVP14]. L’étendue de cette zone géographique peut
varier en fonction du type de l’application (cf. Section 2.3.2.2) ;
— certaines stations de base sont considérées comme réceptrices, ici, BS B, BS E. Il
s’agit des stations de base auxquelles des véhicules sont connectés ;
— les informations sont transmises à un nombre restreint de véhicules (V1, V4)
connus et non à l’ensemble des véhicules (V1, V4, V5, V6, V7). Ces véhicules
se sont signalés comme destinataires auprès de la station de base la plus proche
ou ont été sélectionnés par le contrôleur SDN [DWLZ16]. Ils correspondent no-
tamment aux leaders des clusters véhiculaires (cluster head).
Il est à noter que nous considérons une approche multicast. Les données sont trans-
mises à un nombre limité de stations de base dont l’identité est déterminée par le contrô-
leur SDN (cf. Section 4.5.1). Toutefois, la solution logicielle proposée est applicable aux
différents cas considérés par GeoNet : GeoUnicast, GeoBroadcast, GeoAnycast 3 .
4.4.3 Prédiction de mobilité

Comme indiqué dans la section 4.3.3, la prédiction de mobilité joue un rôle im-
portant dans la limitation des échanges entre contrôleurs SDN et équipements réseau.
En effet, la connaissance des positions futures des terminaux mobiles permet de pré-
déployer des règles de flux et d’assurer, ainsi, la continuité des communications sans
intervention du contrôleur SDN.
10263602v010101p.pdf
88
F IGURE 4.2 – Scénario de distribution géographique considéré
Les modèles de prédiction de mobilité permettent ce calcul des positions futures des
véhicules. Connaissant la position actuelle d’un véhicule (cf. Figure 4.3 : V1 - BS A),
le modèle de mobilité permet de déterminer quelle sera la prochaine station de base à
laquelle se connectera ce véhicule (cf. Figure 4.3 : V1 - BS B).
Pour calculer ces transitions entre stations de base, le Modèle de Markov Ca-
ché (MMC) est une méthode couramment utilisée dans les réseaux véhiculaires
[WPZL16, TBW+ 17]. Avec le MMC, pour un véhicule donné, actuellement connecté à
une station de base donnée (Fig 4.3 : Etat 1), le nombre d’états futurs possibles (nombre
de stations de base auxquelles il peut directement se connecter) est déterminé à partir
des observables. En effet, à partir des informations remontées par les stations de base, il
est possible de savoir quelles sont les transitions possibles. Ces observables fournissent,
également, une autre information : la probabilité de transition d’un Etat 1 vers un Etat
2. Il s’agit de la probabilité qu’un véhicule, actuellement connecté à BS A, se connecte,
ensuite, à BS B (informations provenant des stations de base).
89
F IGURE 4.3 – Exemple de mobilité d’un équipement terminal
Connaissant les états futurs possibles et les probabilités de transition, le contrôleur

SDN va déterminer quelle sera la prochaine station de base à laquelle devrait se connec-
ter un véhicule. Il s’agit de l’état futur avec la plus haute probabilité. Grâce au MMC,
le contrôleur SDN est donc en capacité de pré-déployer des règles de flux permettant
d’assurer la continuité des communications.
Par exemple, sur la figure 4.3, si l’on suppose que la communication vers V1 est
instantiée à t1 (début de l’Etat 1). Le contrôleur SDN, en réponse au Packet In envoyé
par RR1 (cf. Annexe F .), déploiera des règles de flux permettant d’assurer les com-
munications vers V1 durant l’Etat 1 (t2-t1). En utilisant le MMC, il pourra, également,
pré-déployer des règles de flux au niveau de RR1, LR 2, BS B permettant d’assurer les
communications vers V1 durant l’Etat 2. Si la transition supposée entre les cellules (BS
A - BS B) correspond bien à la transition réelle, elle pourra être gérée sans nécessiter
l’envoi d’une requête Packet In. L’utilisation du modèle de prédiction de mobilité permet
donc de limiter les échanges entre contrôleurs SDN et équipements réseau.
4.4.4 Estimation du niveau de charge des stations de base

Pour garantir une gestion efficace des tables de flux dans l’environnement véhicu-
laire, la durée de vie des règles de flux doit correspondre à la durée de connexion entre
les équipements terminaux et les stations de base. Ceci garantit une suppression au-
tomatique des règles inutiles (cf. Section 4.3.4). Or, la durée de connexion entre un
équipement terminal et une station de base est liée, non seulement à la mobilité de
90
ce terminal, mais également au niveau de charge de cette station de base (et de celles
environnantes) [GL17].
En effet, le niveau de charge trop élevé d’une station de base pourrait entraîner
une dégradation des performances (latence, bande passante, perte de paquets). Ceci
est particulièrement vrai dans l’environnement 5G considéré puisqu’il est composé de
cellules de faible rayon. C’est pourquoi différents travaux, dans l’environnement 5G,
se sont intéressés à la définition de politiques de handover considérant la mobilité des
équipements terminaux et le niveau de charge des stations de base.
La prise en compte du niveau de charge des stations de base dans la gestion du
handover s’appuie sur la définition d’un seuil acceptable de charge pour chaque station
de base. Ce seuil peut notamment être défini à partir du Ratio d’Utilisation de Blocs
de Ressources (Resource Block Utilization Rate, (RBUR)). Il s’agit du rapport entre le
nombre total de Blocs de Ressources Physiques (PRB, Physical Resource Blocks) exis-
tants au niveau d’une station de base et le nombre de PRB actuellement utilisés par
les équipements terminaux connectés à cette station de base. Ce RBUR est, par consé-
quent, propre à chaque station de base et calculé dynamiquement. Il est à noter que
l’estimation du nombre de PRB alloués à chaque équipement terminal peut être réali-
sée de façon macroscopique (nombre de PRB/nombre de terminaux) ou microscopique
(rapport signal à bruit de chaque terminal).
Le seuil acceptable de charge peut, ensuite, être utilisé dans la gestion des hando-
vers. Ainsi, si une station de base détecte que son niveau de charge est trop élevé, elle
pourra demander aux stations de base voisines le transfert de certains des équipements
terminaux qu’elle gère actuellement (cf. Section F .). La sélection des terminaux mobiles
devant être transférés dépend de différents paramètres. Tout d’abord, le nombre de PRB
associés à chacun d’eux. Ensuite, leur position (un terminal ne peut être transféré que
s’il est également connecté à une station de base voisine). Enfin leur sens de déplace-
ment (un terminal ne sera transféré qu’à la station de base voisine vers laquelle il se
déplace). Par exemple, si BS A détecte que son niveau de charge est trop élevé, et que
V1 (se déplaçant vers BS B) est à portée de BS A et BS B, BS A va demander à BS B le
transfert de V1.
Grâce aux informations remontées par les équipements terminaux (position, di-
rection, vitesse) et les stations de base (RBUR, PRB total, PRB alloué), les handovers
peuvent donc être gérés efficacement. Ceci garantit une répartition de charge optimale
91
entre les différentes stations de base et des performances (latence, bande passante,
perte de paquets) acceptables. Ceci pourrait, également, permettre une meilleure esti-
mation de la durée des règles de flux, comme ce sera proposé dans la section 4.5.
4.4.5 Résumé
Dans cette section 4.4, nous avons défini l’environnement cellulaire (cf. Section
4.4.1) et le scénario de distribution (cf. Section 4.4.2) considérés pour le déploiement
de notre solution. Nous avons, également, introduit deux outils nécessaires au dévelop-
pement de la solution proposée. Tout d’abord, un modèle de prédiction de mobilité (cf.
Section 4.4.3). Ensuite, une méthode d’estimation du niveau de charge des stations de
base (cf. Section 4.4.4).
4.5 Une approche logicielle performante pour la distri-

bution géographique des données
Dans cette section est introduire la solution logicielle proposée pour la distribution
géographique de données via l’infrastructure cellulaire.
4.5.1 Objectifs
Considérant l’environnement (cf. Section 4.4.1), le scénario (cf. Section 4.4.2) et
les limites (cf. Section 4.2.1) définis, notre objectif est de concevoir une approche lo-
gicielle performante pour la distribution géographique des données via l’infrastructure
cellulaire. La solution proposée doit présenter différentes caractéristiques :
— une utilisation optimale du réseau cellulaire : la capacité des stations de base

est limitée. De plus, les réseaux 5G devraient gérer un nombre important de ter-
minaux mobiles. Il est donc important d’utiliser efficacement les ressources à dis-
position. Pour ce faire, nous proposons une approche permettant de sélectionner
dynamiquement les stations de base destinataires en fonction de leur niveau de
charge et de la position des équipements terminaux (cf. Section 4.5.3.2) ;
— une gestion efficace de la mobilité avec la technologie SDN : les transitions

entre cellules, basées sur une approche réactive, induisent latence et augmenta-
tion de la charge du canal de contrôle. Il parait donc important de définir une
solution garantissant des transitions entre cellules sans intervention du contrôleur
92
SDN. Pour ce faire, nous proposons une nouvelle approche, utilisant un plan de
données avec états pour gérer gérer la mobilité au niveau des équipements réseau
(cf. Section 4.5.4) ;
— une gestion efficace des tables de flux : les tables de flux déployées au niveau
des stations de base auront nécessairement une taille limitée. Aussi, une gestion
efficace des règles de flux déployées au sein de ces tables est essentielle. Pour
ce faire, nous proposons une estimation précise de la durée de vie des règles de
flux. Cette estimation se base sur la mobilité des véhicules et sur le niveau de
charge des stations de base (cf. Section 4.5.3.1). Nous proposons, également, une
politique de pré-déploiement des règles de flux, assurant une utilisation optimale
des ressources à disposition (cf. Section 4.5.5).
4.5.2 Définition des zones de distribution géographique

Le protocole GeoNet 4 propose d’associer certaines adresse IPv6 à des zones géogra-
phiques, correspondant à un ensemble pré-défini de stations de base. Ainsi, lorsqu’un
véhicule transmet une notification, correspondant à une application donnée, il la trans-
met avec une certaine adresse IPv6 de destination que le centre de contrôle sera en
capacité d’interpréter (cf. Annexe E .).
Ce mécanisme d’association entre adresses IPv6 et zones géographiques peut être
utilisé avec SDN. La liste associant zones géographiques et stations de base, stockée
au niveau du centre de contrôle avec GeoNet, est stockée par le contrôleur SDN dans
notre solution. Ainsi, lorsque le contrôleur reçoit une nouvelle requête Packet In, il est
en mesure de déterminer quelles sont les stations de base destinataires en fonction
de l’adresse IPv6 de destination. Il peut donc gérer la distribution de ce paquet. On
considère, également, que cette liste associant adresses IPv6 de destination et stations
de base peut être modifiée à tout moment par l’opérateur du réseau. Ainsi, lorsqu’une
nouvelle station de base est déployée dans une zone existante, elle peut être simplement
ajoutée aux zones de distribution géographiques dont elle dépend.
Ce fonctionnement permet donc d’assurer la distribution géographique des données.
Les mécanismes permettant de gérer les tables de flux (cf. Section 4.5.3.1), de sélection-
4. ETSI EN 302 636-6-1 V1.2.1 (2014-05) Intelligent Transport Systems (ITS) ; Vehicular Communi-
cations ; GeoNetworking ; Part 6 : Internet Integration ; Sub-part 1 : Transmission of IPv6 Packets over
GeoNetworking Protocols https://www.etsi.org/deliver/etsi_en/302600_302699/3026360601/01.
02.01_60/en_3026360601v010201p.pdf
93
ner les stations de base destinataires (cf. Section 4.5.3.2) et la mobilité des utilisateurs
(cf. Section 4.5.4) sont présentés dans les sections suivantes.
4.5.3 Sélection des stations de base réceptrices

Avec le protocole GeoNet, les données sont transmises à l’ensemble des stations de
base situées à l’intérieur d’une zone géographique donnée. Or, distribuer des données à
une station de base n’est pertinent qu’à condition que des équipements terminaux desti-
nataires soient connectés à cette station de base. Nous cherchons donc, ici, à déterminer
à tout instant la position des terminaux destinataires (cf. Section 4.5.3.1). De plus, dans
certains cas, le niveau de charge des stations de base pourrait être élevé. Or, la zone de
distribution géographique de certaines applications est caractérisée par une dimension
minimale et est donc variable. Nous proposons donc également de déterminer, en fonc-
tion du niveau de charge et de la position des stations de base, si les données doivent
ou non leur être transmises (cf. Section 4.5.3.2).
4.5.3.1 Estimation de la durée de connexion entre les stations de base et les

équipements terminaux
L’estimation de la durée de connexion entre les véhicules et les stations de base

présente un double intérêt. Elle permet, tout d’abord, de déterminer, à tout instant t
(t>0), à quelle station de base devrait être connecté chaque équipement terminal (cf.
Section 4.5.3.2). Elle permet, ensuite, de déterminer avec précision la durée de vie
des règles de flux devant être déployées au niveau des équipements réseau (cf. Section
4.3.5).
Jusqu’ici, les travaux portant sur la définition d’une solution logicielle (cf. Section
4.3.4), ont uniquement pris en compte la mobilité des véhicules dans l’estimation de
la durée de connexion entre les véhicules et les stations de base. Les observables (in-
formations remontées par les véhicules et les stations de base) sont alors utilisés pour
classifier les connexions précédentes en fonction de la vitesse des véhicules. Ainsi, un
intervalle de vitesse donné (5km/10km/etc.) peut être associé à un ensemble d’ob-
servables. En moyennant ces observables (durée de connexion effective), une durée
moyenne de connexion pour une vitesse donnée est alors calculée.
La durée de connexion HTx entre une station de base donnée X et tout véhicule Vx
se connectant à cette station de base peut alors être estimée. Il suffit d’associer la vitesse
94
de ce véhicule (ou la vitesse moyenne des véhicules connectés à BS X) à un intervalle

de vitesse et, ainsi, à une durée moyenne de connexion. HTx est donc fonction de la
mobilité (vitesse) des véhicules (HTx ~ f(Vmean).
Toutefois, cette estimation de HTx ne prend pas en compte le niveau de charge
des stations de base. Or, comme nous l’avons indiqué dans la section 4.4.4, les hando-
vers dépendent du niveau de charge des stations de base. Par conséquent, la durée de
connexion entre un équipement terminal et une station de base est directement dépen-
dante du niveau de charge de cette station de base et des stations de base voisines.
C’est pourquoi, nous proposons de classifier les observables en fonction de la vitesse
des véhicules mais également en fonction du niveau de charge des stations de base
[SFGL14, GA17] : faible (<20%), moyen ou élevé (>70%). Plus particulièrement, le
niveau de charge de la station de base à laquelle est actuellement connecté le véhicule
et le niveau de charge de la station de base à laquelle devrait ensuite se connecter ce
véhicule sont considérés.
Ainsi, l’estimation de la durée de connexion entre un véhicule Vx et une station de
base X devient fonction de la vitesse moyenne Vmean de ce véhicule, du niveau de
charge Lx de cette station de base X et du niveau de charge Ly de la station de base Y à
laquelle devrait ensuite se connecter ce véhicule et :
HTx ~ f(Vmean, Lx, Ly)
Cette estimation de la durée de connexion entre un véhicule et une station de base
peut être réalisée en temps réel, en fonction des informations remontées des équipe-
ments réseau et de la classification préalablement réalisée. Elle peut également être
réalisée pro-activement. En effet, à tout instant t, pour une station de base X, de charge
moyenne par utilisateur Lx_u :
— le modèle de prédiction de mobilité peut être utilisé pour déterminer combien de

véhicules N seront connectés à la station de base X à l’instant t ;
— le modèle de prédiction de mobilité peut être utilisé pour déterminer la vitesse

moyenne Vmean des N véhicules qui seront connectés à la station de base X à
l’instant t ;
— la charge totale Lx de la station de base X peut être estimée comme étant égale
à Lx=N*Lx_u. Dans le cas où le contrôleur SDN disposerait également d’informa-
tions concernant les ressources utilisées individuellement par chaque utilisateur,
95
cette charge totale pourrait être calculée de façon plus précise.
Par conséquent, les niveaux de charge et la vitesse des véhicules estimés à l’instant t
peuvent être comparés aux données classifiées.
Les bénéfices de la prise en compte du niveau de charge des stations de base dans
l’estimation de la durée de connexion entre équipements terminaux et stations de base
seront démontrés dans la section 4.6.
4.5.3.2 Prise en compte du niveau de charge des stations de base dans la sélec-
tion des destinataires
Chaque zone géographique correspond à un ensemble pré-déterminé de stations de

base. Cette liste est connue du contrôleur SDN (cf. Section 4.5.2). Ainsi, lorsqu’un équi-
pement terminal transmet des données géographiques à une station de base (cf. Section
4.4.2), le contrôleur SDN sait donc à quelles stations de base ces données pourraient
être transmises.
Néanmoins, il semble peu pertinent d’envoyer ces données à l’ensemble des stations
de base situées dans une zone géographique (cf. Section 4.5.1). Le contrôleur peut
sélectionner les stations de base destinataires en temps réel, en réponse à un Packet In.
Il peut, également, les sélectionner pro-activement. Ceci permettra de limiter la latence
liée à l’instanciation des chemins de communication et de limiter le nombre de requêtes
Packet In.
Le modèle de mobilité permet de déterminer quelle sera la prochaine transition de
chaque terminal et combien de temps il restera connecté à cette station de base future
(cf. Section 4.4.4). Par conséquent, la combinaison des informations remontées par les
équipements réseau (Packet In) et des informations fournies par le modèle de mobilité
(transitions, durées) permet au contrôleur SDN de déterminer la position de l’ensemble
des équipements terminaux à tout instant t. A tout instant t, il est donc en mesure de
savoir quelles stations de base sont/seront des stations de base réceptrices. Il s’agit de
celles auxquelles des terminaux destinataires sont/seront connectés.
Jusqu’ici, les solutions existantes considèrent que les données sont transmises à l’en-
semble de ces stations de base réceptrices (cf. Section 4.3.2). Néanmoins, comme nous
l’avons noté dans la section 2.3.2.2, pour certaines applications C-ITS, les dimensions
de la zone de distribution ne correspondent pas nécessairement à une valeur fixe.
96
Par exemple, pour les applications de création coopérative de cartes HD, de strea-
ming vidéo coopératif ou de prévention coopérative de collision une zone minimale est
définie : 1 kilomètre. Des stations de base situées à moins d’un kilomètre et d’autres
situées à plus d’un kilomètre seront donc contenues dans la zone de distribution. La
transmission des données à certains stations de base est donc nécessaire : celles situées
à l’intérieur de la zone minimale de dissémination. En revanche, pour d’autres, la trans-
mission est optionnelle : celles situées à l’extérieur de la zone minimale.
C’est pourquoi, nous proposons d’ajouter une nouvelle information à la liste asso-
ciant zone géographique et station de base : le statut de ces stations de base (né-
cessaire/optionnelle). Ainsi, le contrôleur sait à quelles stations de base les données
doivent impérativement être transmises et à quelles autres elles ne doivent l’être que si
le niveau de charge des stations de base le permet. Les réseaux cellulaires 5G doivent
permettre le déploiement d’un nombre varié d’applications (cf. Section 2.3.3.2). Cette
sélection des stations de base destinataires permet de limiter le coût associé au déploie-
ment des applications C-ITS.
Pour une application donnée, à un instant t, pour déterminer si les données doivent
être transmises à une station de base X optionnelle, le contrôleur se base sur différents
paramètres. Tout d’abord, le niveau de charge estimé Lx de cette station de base à l’ins-
tant t. Puis, le seuil de charge (Sx) acceptable pour cette station de base. Ensuite, la
charge moyenne par utilisateur Lx_u. Enfin, le nombre d’équipements terminaux récep-
teurs N qui seront connectés à cet instant à la station de base. Grâce à ces différentes
informations, il peut déterminer si les données doivent ou non être transmises :
Lx + N*Lx_u < ?> Sx
Si la transmission de données à BS X risque d’entraîner un niveau de charge trop
important, supérieur au seuil Sx de cette station de base, le contrôleur SDN retire cette
station de base de la liste des récepteurs. De même, si le contrôleur détecte un niveau de
charge trop important pour BS X, il commence par vérifier si des données géographiques
transmises à cette station de base sont optionnelles. Si c’est le cas, il retire les règles de
flux correspondantes. Comme cela sera montré dans la section 4.5.4, il sera également
possible pour le contrôleur SDN de ne transmettre les données qu’à un nombre restreint
de terminaux connectés à une station de base ayant un niveau de charge élevé.
Ce mécanisme prend donc en compte la position des équipements terminaux et le
niveau de charge des stations de base. Il permet de garantir une meilleure utilisation
97
des ressources à disposition et une réduction du coût associé aux applications C-ITS.
Les bénéfices de cette approche seront démontrés dans la section 4.6.
4.5.4 Automatisation des transitions entre états

Grâce au mécanisme de sélection des stations de base destinataires (cf. Section
4.5.3.2), le contrôleur SDN peut gérer la distribution des données. Pour ce faire, il doit
déterminer au niveau de quels équipements réseau des règles de flux doivent être dé-
ployées, en temps réel (Packet In) ou pro-activement (cf. Section 4.5.1). Pour garantir la
continuité des communication, à chaque instant, les règles de flux utilisées par les équi-
pements réseau doivent correspondre à la position réelle des terminaux destinataires.
Par exemple, sur la figure 4.3, à l’Etat 1, le contrôleur SDN doit déployer des règles
de flux permettant de transmettre les données à BS A et V1. Les tables de flux de RR
1, LR1 et BS A sont affectées. A l’Etat 2, il doit déployer des règles de flux permettant
de transmettre des données à BS B et V1. Les tables de flux de RR1, LR2 et BS B sont
affectées. Le remplacement des règles de flux nécessaires à l’Etat 1 par celles nécessaires
à l’Etat 2 doit se produire au moment exact du handover de V1 de BS A vers BS B. Sans
cela, les équipements réseau transmettront une requête Packet In au contrôleur SDN (cf.
Annexe F .), induisant latence et augmentation de la charge du canal de contrôle.
Les solutions proposées jusqu’ici se basent uniquement sur des paramètres tempo-
rels pour la transition entre états (cf. Section 4.3.3). Autrement dit, lorsque plusieurs
états successifs sont déployés, l’état n est remplacé par l’état n+1 à l’instant où la du-
rée de vie des règles de flux de l’état n arrive à sa fin. Or, l’estimation de la durée de
connexion entre une station de base et un équipement réseau est nécessairement im-
précise (cf. Section 4.5.3.1). Aussi, le handover ne se produira pas nécessairement au
moment estimé de la transition.
C’est pourquoi, pour le déploiement des règles de flux et la gestion des transitions
entre états, nous proposons de considérer deux paramètres. Tout d’abord, la durée de
connexion entre les équipements réseau et les stations de base. Ensuite, les informations
de connexions remontées par les stations de base. En effet, cette information, concer-
nant les nouvelles connexions, est transmise par les stations de base aux routeurs du
coeur du réseau (cf. Figure 7.4).
Comme cela a été démontré dans [SBC+ 17, CSP+ 17, CPSC15], ces informations
pourraient être utilisées par les routeurs du coeur du réseau sans nécessiter l’interven-
98
tion du contrôleur SDN. Pour ce faire, un nouvel élément doit être intégré aux switches
OpenFlow : une table d’états (cf. Annexe H .). Cette table d’état permet à un équipement
réseau de modifier son comportement (règle de flux utilisée) en fonction d’évolutions
du réseau (rupture d’un lien) ou de paramètres temporels (cf. Annexe G .). Par consé-
quent, un routeur, recevant une notification de connexion, pourrait modifier son état
(règle de flux utilisée) au moment exact d’un handover. Ces tables de flux pourraient
donc permettre de gérer efficacement la mobilité dans l’environnement véhiculaire.
Pour la distribution géographique de données, un état correspond à la connexion
entre un équipement réseau et une station de base. Lorsque le contrôleur SDN reçoit
une nouvelle requête Packet In, cela signifie qu’un équipement terminal V vient de se
connecter à une nouvelle station de base X et que le contrôleur SDN n’avait pas anticipé
ce déplacement. Dans ce cas, il adopte la procédure suivante :
— si des véhicules étaient déjà connectés à la station de base X : cela signifie que
les chemins nécessaires pour établir une communication vers la station de base
X sont déjà déployés. Par conséquent, le contrôleur SDN doit simplement ajuster
la durée de vie des règles déployées au niveau des routeurs en fonction de la
durée de la connexion entre V et X. Il doit, également, ajouter, au niveau de X,
une règle de flux permettant de distribuer les données à V. Par exemple, sur la
figure 4.2, si V se connecte à la station de base E, V4 y est déjà connecté. Aussi, les
chemins de communication permettant de distribuer les données géographiques
vers BS E (BS C - BS E) sont déjà en place. Pour les routeurs (RR1, RR2, LR3), le
contrôleur SDN allonge la durée de vie des règles de flux permettant de distribuer
les données à BS E (si elle est inférieure à la durée de connexion entre BS E et
V). Il ajoute, également, une règle de flux au niveau de la station de base BS E.
Celle-ci permettra de distribuer les données à V ;
— si aucun véhicule n’était connecté à la station de base X : cela signifie que les
chemins nécessaires pour établir une communication vers la station de base X ne
sont pas déployés. Dans ce cas, le contrôleur SDN commence par déterminer dans
quelles zones géographiques se situe la station de base X. Il évalue, également, le
niveau de charge de cette station de base et détermine quels chemins de communi-
cation doivent être déployés (nécessaires/optionnels). Ensuite, il déploie les règles
de flux correspondantes en calculant la durée de vie des chemins en fonction de
la durée de connexion entre la station de base X et le véhicule V. Par exemple,
99
si un véhicule se connecte à la station de base D, celle-ci deviendra réceptrice et

l’ajout d’un chemin de communication entre BS C et BS D est donc nécessaire. Le
contrôleur détermine le chemin le plus court (latence de bout en bout) de BS C
vers BS D et déploie les règles nécessaires (RR2, LR3). Il ajoute, ensuite, une règle
au niveau de BS D pour distribuer les données à V. La durée de vie de l’ensemble
de ces règles correspond à la durée de connexion entre BS D et V.
Dans l’exemple général d’une station de base X et d’un véhicule V, une fois que cette
opération a été réalisée pour la position actuelle de V, le contrôleur SDN va chercher à la
répéter pour les positions futures de V. Ceci permettra de gérer, par la suite, la mobilité
de V sans l’envoi d’une requête Packet In. Ainsi, estimant que le prochain déplacement
de V vers une station de base Y devrait se produire à l’instant t, le contrôleur répète
le même processus. En fonction des règles qu’il a déjà pré-déployées, il regarde si à
l’instant t une communication vers Y sera déjà assurée. En fonction de cela, il applique
la procédure que l’on vient de décrire, ajoutant ou modifiant des règles de flux/états
présent(e)s dans la table des flux/table d’états.
Par exemple, sur la figure 4.2, si à l’instant t, le véhicule V1 se connecte à la station
de base B, il sera le seul récepteur. Aussi, la transmission de données à BS B, à l’instant t,
dépend uniquement de la position de V1. Elle doit donc correspondre au moment exact
du handover de BS A vers BS B. Les informations remontées par BS B, indiquant à RR1
qu’un nouveau véhicule vient de se connecter, sont utilisées pour gérer cette transition
au niveau de RR1. Lorsque RR1 reçoit cette notification, il cesse l’envoi de données à
BS A et commence l’envoi de données à BS C.
Il est à noter que la gestion future de la mobilité des véhicules est réalisée de façon
incrémentale. Ainsi, tant que la politique de pré-déploiement le permet (cf. Section
4.5.5), le contrôleur SDN va traiter une à une les positions successives d’un véhicule
donné. L’ensemble de ce processus est présenté avec l’algorithme 1.
L’approche présentée dans cette section garantit une gestion efficace de la mobilité
des véhicules mais également des tables de flux des équipements réseau. En effet, la
gestion de la mobilité, s’appuyant sur des tables d’états, permet de réaliser des transi-
tions entre états correspondant à l’état réel du réseau. De plus, l’estimation de la durée
de connexion entre les véhicules et les stations de base permet de définir des règles de
flux à durée limitée.
100
Algorithme 1 : Solution proposée pour le déploiement pro-actif des règles

de flux
Input : Packet In pour un véhicule V connecté à une station de base BS X
Output : Règles de flux à déployer/pré-déployer
Variables : dest_BS=X, state_n=1, state_n_start=0, stat_n_HT=0;
while (true);
Etape 1 : récupération des informations de distribution;
-> 1.1 mesure du niveau de charge de BS X X_load;
->1.2 sélection des stations de base émettrices à considérer pour BS X en fonction de la
position, du statut et du niveau de charge de BS X : L_n_orig;
-> 1.3 mesure du niveau de charge du canal de contrôle : C_load;
Etape 2 : récupération des informations concernant state_n;
-> 2.1 calcul du moment d’instantiation de cet état : state_n_start;
if state_n = 1;
state_n_start = current_time;
else;
state_n_start=state_n-1_start+state_n-1_HT;
-> 2.2 calcul de la durée de cet état (durée de connexion) : state_n_HT;
-> 2.3 calcul du coût associé à ce pré-déploiement (utile lorsque le canal de contrôle est
chargé) : state_n_P;
Etat 3 : Calcul des chemins de communication nécessaires pour cet état;
for each station in L_n_orig;
calcul du plus court chemin entre station et BS X : L_n;
if L_n déployé à state_n_start;
for each device in L_n;
on récupère la règle déployée : F_d_n;
on mesure le taux d’utilisation : Oc_d_n;
else;
on calcule la règle à déployer : F_d_n;
on mesure le taux d’utilisation : Oc_d_n;
if device était utilisé dans l’état précédent de V;
on définit la règles à déployer comme un nouvel état pour device;
Etape 4 : Gestion du pré-déploiement;
if (state_n=1);
-> on déploie la règle F_d_n avec HT=state_n_HT;
else
if (C_load="low");
if (Oc_d_n="low");
-> on pré-déploie F_d_n avec HT=state_n_HT;
if (Oc_d_n="high");
-> on pré-déploie F_d_n avec HT=ecart_max_entre_est_et_realite;
if (C_load="high");
if (Oc_d_n="low");
if (state_n_P="minimise_rules_number");
-> on pré-déploie F_d_n avec HT=state_n_HT;
Etape 5 :Prise en compte de l’état suivant;
if (Oc_d_n="high" AND state_n+1_P !="minimise_rules_number" AND C_load="high");
-> return False ;
101
4.5.5 Point d’équilibre entre canal de contrôle et tables de flux

Les mécanismes proposés dans ce chapitre permettent de gérer de façon efficace
la mobilité des véhicules et la distribution géographique des données. Toutefois, pré-
déployer un nombre trop important d’états successifs pourrait s’avérer peu pertinent. Par
exemple, sur la figure 4.3, la probabilité que le véhicule V1 se déplace de la station de
base BS A vers la station de base BS B pourrait être égale à 10%. Aussi, 9 fois sur 10 une
entrée serait occupée de façon inutile dans la table des flux de BS B. Une requête Packet
In serait également envoyée au contrôleur SDN. Répétée pour de nombreux véhicules,
cette opération pourrait entraîner une augmentation significative de la charge du canal
de contrôle et du taux d’occupation des tables des flux.
C’est pourquoi, afin d’améliorer les performances, nous proposons une politique de
pré-déploiement des règles de flux. Cette politique de pré-déploiement s’appuie sur dif-
férents paramètres. Il s’agit du taux d’occupation de la tables des flux, du niveau de
charge du canal de contrôle (entre les équipements réseaux et le contrôleur SDN) et de
la probabilité de transition entre deux états pour un véhicule. En fonction de la valeur
de ces paramètres, différents cas sont considérés (cf. Etapes 4 et 5 de l’Algorithme 1) :
— si le niveau de charge du canal de contrôle et le taux d’occupation de la table des
flux sont bas : les ressources peuvent alors être considérées comme illimitées, le
déploiement de nombreux états successifs peut être envisagé ;
— si le niveau de charge du canal de contrôle est bas et le taux d’occupation de la
table des flux est élevé : un pré-déploiement avec une durée de vie plus courte de
la règle de flux peut être considéré. Cette durée de vie pourrait notamment corres-
pondre à l’écart maximal mesuré entre la durée de connexion estimée et la durée
de connexion réelle au niveau de la station de base concernée (cf. Section 4.6.3).
Ainsi, si la transition réelle correspond à la transition supposée, le contrôleur SDN
pourra allonger la durée de vie de cette règle de flux (n’ayant pas reçu de Packet In
il pourra être assuré que cette transition s’est produite). Dans le cas contraire, elle
sera automatiquement supprimée après une durée plus courte que la durée suppo-
sée (durée de connexion théorique). Ainsi cette approche permet de garantir des
transitions efficaces (lorsque la mobilité réelle correspond à la mobilité supposée)
et réduit le taux d’occupation des tables de flux ;
— si le niveau de charge du canal de contrôle est élevé et le taux d’occupation de
102
la table des flux est bas : les règles de flux ne sont pré-déployées qu’à condition
que le nombre total de règles de flux déployées soit minimisé grâce à ce pré-
déploiement. Ainsi, considérant que la probabilité de transition est égale à Ptr, que
le pré-déploiement de Npre règles est nécessaire, qu’au maximum Neffect règles
devront être déployées par le contrôleur SDN si ce déplacement ne se produit pas
et que le nombre moyen de règles devant être déployées en réponse à un Packet
In est égal à Mpacket, les règles ne sont pré-déployées qu’à condition que :
Npre + (1-Ptr)(Neffect+1) < Mpacket +1
Ainsi, cette approche permet de s’assurer que le nombre de messages transitant

par le canal de contrôle est minimal ;
— si le niveau de charge du canal de contrôle et le taux d’occupation de la table

des flux sont élevés : une politique de "best effort" est adoptée. Ainsi, les tables
de flux et le canal de contrôle ne sont utilisés que pour gérer les flux essen-
tiels. Une approche réactive est donc utilisée. Les flux sont pré-calculés mais ne
seront déployés qu’en réponse à un Packet In, à l’image de ce qui est proposé
dans [BMO16, AMS20]. Cette approche entraîne donc une dégradation des per-
formances mais limite l’utilisation des ressources.
Ainsi, cette politique de pré-déploiement permet de garantir une utilisation optimale

des ressources, comme cela sera démontré dans la section 4.6.
Il est à noter que le pré-déploiement des règles de flux peut être basé sur deux
mécanismes. Les règles de flux peuvent être déployées au niveau des équipements ré-
seau, dans un espace de cache dédié à cet effet [CWWL18]. Elles peuvent, également,
être déployées après une période pré-déterminée, inférieure à la durée de vie de l’état
précédent [MCK19b]. Quel que soit la solution considérée, le pré-déploiement permet
de garantir que les règles de flux seront déployées au sein des équipements réseau au
moment où elles seront nécessaires.
Il est également à noter que 70% peut être considéré comme un niveau d’occupation
élevé pour les tables de flux. Comme cela est noté dans [ZFLJ15], la mise en place d’une
politique de gestion des tables de flux, telle que décrite dans cette section, pourrait
permettre de limiter les risques de surcharge.
103
4.5.6 Résumé
Dans cette section nous avons introduit une nouvelle approche, devant garantir une
distribution efficace des données géographiques grâce à SDN (cf. Section 4.5.1). La
solution proposée se base sur quatre mécanismes principaux. Tout d’abord, une prise
en compte du niveau de charge des stations de base dans l’estimation de la durée de
vie des connexions entre les équipements terminaux et les stations de base (cf. Section
4.5.3.1). Ensuite, une sélection dynamique des stations de base destinataires en fonction
de la position des équipements terminaux et du niveau de charge de ces stations de
base (cf. Section 4.5.3.2). Puis, la définition de machines d’états permettant de gérer
la mobilité des équipements terminaux de façon plus efficace (cf. Section 4.5.4). Enfin,
la proposition d’une politique de pré-déploiement des règles de flux visant à optimiser
l’utilisation du canal de contrôle et les tables de flux (cf. Section 4.5.5).
4.6 Évaluation des performances

Dans cette section, la solution proposée (cf. Section 4.5) est comparée aux approches
introduites dans la littérature (cf. Section 4.3.5).
4.6.1 Objectifs
Considérant nos objectifs initiaux (cf. Section 4.2.1), dans cette expérimentation
nous avons décidé d’évaluer :
— les bénéfices, en terme d’utilisation des tables de flux, du mécanisme proposé pour
l’estimation de la durée de connexion entre équipements terminaux et stations de
base (cf. Section 4.6.3) ;
— les bénéfices liés à la sélection dynamique des stations de base destinataires en

fonction de leur niveau de charge (cf. Section 4.6.4) ;
— les bénéfices permis par l’utilisation des machines d’états pour la gestion de la
mobilité des véhicules (cf. Section 4.6.5) ;
— les bénéfices de la politique de pré-déploiement des règles de flux proposée (cf.

Section 4.6.6).
104
4.6.2 Environnement de test

Pour mener à bien cette expérimentation, nous nous sommes basés sur différents
outils :
— Mininet-Wifi : un framework permettant l’émulation de réseaux sans fil définis
logiciellement [FAB+ 15] ;
— SUMO (Simulation of Urban MObility) : un simulateur de trafic routier permet-
tant de simuler le déplacement de véhicules dans une zone géographique donnée
[BBEK11] ;
— Ryu : un framework SDN, écrit en Python, utilisé dans de nombreux travaux
de recherche pour l’évaluation de solutions basées sur une approche logicielle
[SHV+ 15] ;
— FlowVisor : un outil SDN permettant la mise en place d’un proxy entre des équi-
pements réseau et des contrôleurs SDN. Cet outil a été utilisé pour la simulation
de la solution considérant plusieurs contrôleurs SDN 5 ;
— iPerf : un outil permettant de générer du trafic et de mesurer la bande passante
maximale réalisable dans des réseaux IP [Dug10].
Il est à noter que l’implémentation de la solution proposée et les ou-
tils/scripts/paramètres utilisés pour cette expérimentation sont accessibles en ligne 6 .
Les paramètres de simulation considérés durant l’expérimentation sont présentés
dans le tableau 4.2.
Pour simuler un environnement se rapprochant des réseaux cellulaires 5G (cf. Sec-
tion 4.4.1), nous avons considéré le déploiement de small cells. Celles-ci sont uniformé-
ment réparties dans l’aire de simulation de 600m par 600m (distribution par grille) avec
un rayon de couverture de 100m et des sites situés à 200m les uns des autres [TS15].
Le mécanisme de handover Least Loaded First [LHJ17], disponible avec Mininet-Wifi, a
été utilisé dans cette simulation.
Dans la zone de simulation ainsi définie, un nombre variable de véhicules (18-36),
se déplaçant à des vitesses variables (8-20m/s), a été considéré. La modèle de mobilité
utilisé pour simuler leurs déplacements est un modèle couramment utilisé dans la simu-
lation de scénarios de mobilité urbaine : le modèle de mobilité de Manhattan [SSR16].
5. https://github.com/OPENNETWORKINGLAB/flowvisor/wiki
6. Github repository : github.com/lmendiboure/LAMAP/
105
Paramètre Valeur
Aire de simulation 600m*600m
Nombre de BS 9
Distribution des BS Grid-based
Rayon de communication des BS 100m
Nombre de zones de distribution 2
Stations de base nécessaires/optionnelles par zone 4/1
Nombre de véhicules 18-36
Vitesse des véhicules 8-20m/s
Modèle de Mobilité Manhattan [SSR16]
Précision du modèle de mobilité 70-80%
Distribution de la charge Uniforme/Gaussienne
Algorithme de balancement de charge Least Loaded First[LHJ17]
Nombre de flux concurrents envoyés 18-36/63-126
Durée d’expérimentations 3600s
Nombre total de flux reçus ~11000~40000
Tableau 4.2 – Paramètres de simulation
Un scénario simple de distribution géographique de données, présenté dans la figure

7.8, a été considéré. La zone de simulation a été séparée en deux zones de distribution
distinctes. Chacune correspond à un ensemble de cinq (5) stations de base. Parmi ces
5 stations de bases, quatre (4) d’entre elles sont considérées comme étant nécessaires.
Tandis que la cinquième, est considérée comme étant optionnelle.
Dans cet environnement, nous avons comparé notre solution, que nous notons LA-
MAP (Load Aware and Mobility Aware Pre-deployment), prenant en compte la charge des
stations de base, et permettant le pré-déploiement de règles de flux, à d’autres solutions
proposées dans la littérature :
— une approche proposant de pré-calculer les règles de flux nécessaires à la gestion
de la mobilité des équipements terminaux (MA, Mobility Aware) [BMO16]. Dans
cette approche, un modèle de Markov est utilisé pour prédire la mobilité des équi-
pements terminaux et pré-calculer les règles de flux devant être déployées. Cette
approche assure une réponse plus rapide du contrôleur SDN. Toutefois, l’idée de
pré-déploiement n’est pas considérée ;
— une approche proposant de pré-calculer les règles de flux nécessaires à la ges-
tion de la mobilité et de distribuer la charge entre différents contrôleurs SDN
(DMA,Distributed Mobility Aware) [YWP+ 16]. Allant plus loin que l’approche MA,
106
l’approche DMA considère un plan de contrôle distribué (2 contrôleurs dans l’ex-

périmentation menée). Avec cette approche, le plan de contrôle pourrait être ca-
pable de gérer un nombre supérieur de requêtes par seconde, réduisant encore
le délai de réponse du plan de contrôle. Toutefois, avec cette approche, l’idée de
pré-déploiement n’est pas non plus considérée ;
— une approche proposant de pré-calculer et pré-déployer les règles de flux néces-

saires à la gestion de la mobilité des équipements terminaux (MAP, Mobility Aware
Pre-deployment). Contrairement aux approches MA et DMA, l’approche MAP consi-
dère le pré-déploiement des règles des flux. Avec cette approche, les transitions
entre états s’appuient uniquement sur des paramètres temporels et non sur l’utili-
sation de machines d’états (cf. Section 4.3.5).
Pour chacune des solutions, un même niveau de précision a été considéré pour le
modèle de prédiction de mobilité : 70 à 80% en fonction des stations de base. Cette va-
leur correspond aux performances mesurées pour des modèles de mobilité Markoviens
[BMO18]. Cette définition d’un même niveau de précision permet de s’assurer que les
bénéfices mesurés sont liés à la solution évaluée (LAMAP, MA, DMA, MAP) et non au
modèle de mobilité sous-jacent.
Deux cas ont été considérés pour évaluer les performances de la solution proposée :
— Charge uniforme (UL, Uniform Load) : la charge est uniformément répartie entre
les différentes stations de base. Un même nombre de véhicules (2-4) est connecté
à chaque station de base. Chaque véhicule génère une même quantité de données
avec Iperf ;
— Charge non uniforme (NL, Non-uniform Load) : suivant une distribution gaus-
sienne, la charge est non uniformément répartie entre les différentes stations de
base. Un même nombre de véhicules (2-4) est connecté à chaque station de base.
Toutefois, avec Iperf, chaque véhicule génère une quantité variable de flux de don-
nées.
On peut noter que, pour chacun des cas considérés (UL, NL) et pour chacune des
solutions évaluées (LAMAP, MA, DMA, MAP), une simulation d’une heure a été réalisée.
107
4.6.3 Estimation de la durée de connexion

La première amélioration proposée est la prise en compte du niveau de charge des
stations de base dans l’estimation de la durée de connexion entre les équipements ter-
minaux et les stations de base (cf. Section 4.5.3.1). Dans cette évaluation, nous avons
comparé notre solution (LAMAP) à l’approche MAP dans les cas UL (LAMAP-UL, MAP-
UL) et NL (LAMAP-NL, MAP-NL). Toutefois, les résultats présentés dans cette section
sont également valides pour les approches MAP et DMA. En effet, les solutions exis-
tantes (MA, DMA, MAP) considèrent toutes une même approche pour l’estimation de la
durée de connexion (cf. Section 4.3.4).
Cette estimation de la durée de connexion entre les terminaux et les stations de base
sert notamment à déterminer la durée de vie des règles de flux déployées au niveau des
équipements réseau. Grâce à ce mécanisme, ces règles de flux seront automatiquement
supprimées de la table des flux. Plus l’estimation est précise, plus les tables de flux
seront utilisées efficacement.
Aussi nous avons cherché à évaluer pour LAMAP-UL, MAP-UL, LAMAP-NL et MAP-NL
le pourcentage de différence entre la durée de connexion estimée (e_dur) et la durée
réelle de connexion (a_dur) :
100*(e_dur-a_dur)/a_dur
F IGURE 4.4 – Comparaison des mécanismes d’estimation de la durée de connexion
Comme nous pouvons le constater sur la figure 4.4, présentant la fonction de distri-
bution cumulative (CDF, Cumulative Distribution Function) :
— dans le cas UL, les performances moyennes des deux approches sont similaires. Le
pourcentage moyen de différence entre la durée réelle et la durée estimée pour
108
les approches LAMAP et MAP est le même : 8%. De plus, pour environ 50% des
connexions, l’approche MAP est plus performante (de 5 à 25% plus précise). De
même, pour environ 50% des flux, l’approche LAMAP est plus performante (de
8 à 33% plus précise). Toutefois, il est à noter que l’approche proposée permet
de réduire le pourcentage de différence maximal mesuré (15% contre 20% pour
l’approche MAP). Même dans un cas de répartition de charge uniforme, la prise
en compte du niveau de charge dans l’estimation de la durée de connexion entre
véhicule et station de base semble donc pouvoir être bénéfique ;
— dans le cas NL, l’approche proposée permet une amélioration importante de l’es-
timation de la durée de connexion. En moyenne, l’approche LAMAP garantit des
performances 22% plus élevées que l’approche MAP. De plus, dans le pire des cas,
l’approche améliore les performances de plus de 100% (15% vs 34%). Ainsi, dans
le cas NL, l’approche proposée garantit une fiabilité plus élevée dans l’estimation
de la durée de connexion et, par conséquent, une gestion plus efficace des tables
de flux.
Dans le cas UL, l’équilibrage de charge est directement lié à la mobilité des véhicules.
Aussi, la différence entre l’approche MAP et l’approche LAMAP est faible. Néanmoins,
les véhicules sont hautement mobiles et une répartition uniforme de la charge entre les
différentes stations de base parait peu réaliste. Aussi, la prise en compte du niveau de
charge des stations de base dans l’estimation de la durée de connexion entre station de
base et équipement terminal pourrait permettre une gestion plus efficace des tables de
flux.
4.6.4 Sélection des stations de base destinataires

La seconde amélioration proposée est la définition d’un statut pour les stations de
base (nécessaire/optionnelle). Lorsque le niveau de charge des stations de base est
élevé, ceci permet d’améliorer le processus de distribution des données en déterminant
quels flux de données doivent être transmis (cf. Section 4.5.3.2).
Dans cette évaluation, nous avons comparé notre solution (LAMAP) à l’approche
MAP dans les cas UL (LAMAP-UL, MAP-UL) et NL (LAMAP-NL, MAP-NL). Les résultats
présentés dans cette section sont également vrais pour les approches MAP et DMA.
En effet, les solutions existantes (MA, DMA, MAP) utilisent un mécanisme similaire.
L’ajout de nouveaux flux est réalisé tant que les ressources (bande passante) des sta-
109
tions de base le permettent. Les stations de base nécessaires et optionnelles ne sont pas
différenciées.
Dans notre scénario nous avons choisi deux stations de base impliquées dans les
zones géographiques de distribution (cf. Annexe I .). Chacune d’entre elles est option-
nelle pour une des deux zones géographiques et nécessaire pour l’autre. Nous avons
considéré que leur niveau de charge est élevé et que seul un nombre restreint de nou-
veaux flux peut être ajouté. Pour ces stations de base, nous avons cherché à démontrer
que l’approche LAMAP permet d’assurer une meilleure distribution des données. Pour
ce faire, nous avons mesuré pour LAMAP-UL, MAP-UL, LAMAP-NL et MAP-NL le pour-
centage de flux accepté moyen pour ces deux stations de base. Le niveau de charge
des stations de base étant élevé, le nombre de nouvelles demandes de flux (nouveau
destinataire) qu’elles sont en mesure d’accepter est nécessairement réduit. Le pourcen-
tage de flux accepté correspond à la différence moyenne mesurée entre le nombre total
de requêtes envoyées au contrôleur SDN et le nombre de requêtes acceptées par ce
contrôleur durant l’expérimentation. Ce pourcentage a été mesuré en considérant la sé-
paration entre les flux nécessaires et les flux optionnels et en moyennant les résultats
des deux stations de base impliquées.
Paramètre Flux nécessaires Flux optionnels

LAMAP-UL : 92 LAMAP-UL : 56
Pourcentage d’acceptation moyen LAMAP-NL : 91 LAMAP-NL : 58
mesuré durant l’expérimentation MAP-UL : 70 MAP-UL : 73
MAP-NL : 72 MAP-NL : 68
LAMAP-UL : 88 LAMAP-UL : 31
Pourcentage d’acceptation minimal LAMAP-NL : 85 LAMAP-NL : 22
mesuré durant l’expérimentation MAP-UL : 66 MAP-UL : 64
MAP-NL : 51 MAP-NL : 52
LAMAP-UL : 98 LAMAP-UL :72
Pourcentage d’acceptation maximal LAMAP-NL :99 LAMAP-NL : 86
mesuré durant l’expérimentation MAP-UL :90 MAP-UL : 88
MAP-NL :86 MAP-NL : 89
Tableau 4.3 – Évaluation du processus de sélection des stations de base destinataires
Ce que l’on peut conclure du tableau 4.3 est que :

— l’approche LAMAP est plus performante que l’approche MAP pour la distribution
des flux nécessaires, quel que soit le cas considéré (UL, NL). Le pourcentage d’ac-
ceptation moyen pour les flux nécessaires est augmenté d’environ 25%, tant dans
le cas NL que UL. De même, les pourcentages d’acceptation maximaux sont amé-
110
liorés. Les flux nécessaires sont donc distribués à un nombre plus élevé de véhi-
cules destinataires ;
— l’approche LAMAP entraîne une détérioration importante des performances pour

le flux optionnel. Les flux nécessaires étant déployés en priorité, l’approche LAMAP
ne traite les flux optionnels que lorsque cela est possible. Aussi, le pourcentage
d’acceptation moyen est réduit de près de 16%, tant pour les cas UL que NL. Cette
différence est encore plus importante pour le pourcentage d’acceptation minimal.
Elle dépasse ainsi les 100%.
Considérant que les dimensions de la zone de distribution de certaines applications

sont caractérisées par une borne minimale (cf. Section 4.5.3.2), l’approche LAMAP per-
met d’améliorer le processus de distribution. En effet, les stations de base nécessaires
sont desservies en priorité. Ceci garantit un pourcentage d’acceptation plus élevé pour
les flux prioritaires. Par conséquent, ce processus de sélection garantit une meilleure
utilisation des ressources et des performances plus élevées pour les applications C-ITS.
4.6.5 Gestion des transitions entre états

Le troisième mécanisme proposé consiste à utiliser des tables d’états (cf. Annexe
H .) pour la gestion de la mobilité des véhicules (cf. Section 4.5.4). Aussi, dans cette
section, nous avons cherché à évaluer les bénéfices de notre approche (LAMAP) prenant
en compte les informations remontées par les équipements réseau. LAMAP a ainsi été
comparée aux approches se basant uniquement sur des paramètres temporels pour la
gestion de la mobilité (MA, DMA, MAP). Nous avons réalisé cette comparaison dans
le cas d’une répartition de charge uniforme (LAMAP-UL, MAP-UL, MA-UL, DMA-UL) et
dans le cas d’une répartition de charge non uniforme (LAMAP-NL, MAP-NL, MA-NL,
DMA-NL).
Une gestion efficace de la mobilité des équipements terminaux doit permettre de
(1) minimiser la latence liée à la reconfiguration du réseau et (2) limiter le nombre
d’échanges entre le contrôleur SDN et les équipements réseau. C’est pourquoi, dans le
cadre de cette expérimentation, nous avons mesuré :
— le délai de récupération : le temps écoulé entre le dernier paquet (l_pckt) reçu

par un véhicule au niveau de la station de base à laquelle il était précédemment
connecté et le premier paquet (n_pckt) reçu par ce véhicule au niveau de la station
111
de base à laquelle il est actuellement connecté. Le délai de récupération est donc

égal ici à la différence entre le timestamp de (l_pckt) et le timestamp de (n_pckt) ;
— le surcoût de contrôle : le nombre de requêtes Packet In envoyées par une station
de base donnée au contrôleur SDN pour gérer la connexion d’un véhicule donné.
Ainsi, lorsque des règles de flux sont pré-déployées, il est possible qu’il n’y ait
aucun surcoût. En revanche, dans certains cas, l’envoi d’une ou plusieurs requêtes
Packet In est possible.
F IGURE 4.5 – Comparaison des mécanismes de transition entre stations de base
Comme on peut le constater sur la figure 4.5 :
— l’approche LAMAP garantit un délai de récupération moyen inférieur aux autres

solutions (MA, DMA, MAP), quel que soit le cas considéré (UL, NL). Ainsi, par
rapport à l’approche MA, le gain moyen est de 10% et 14% pour, respectivement,
les distributions UL et NL. Par rapport à l’approche MA, le gain moyen est de 90%
(UL) et 96% (NL). La solution proposée permet, également, de réduire le nombre
de requêtes Packet In transmises au contrôleur SDN. Par exemple, par rapport à
112
l’approche MAP, permettant également une réduction du nombre d’échanges, les

gains avec l’approche LAMAP sont d’environ 5% pour la distribution UL et de plus
de 30% dans le cas de la distribution NL ;
— l’approche DMA, considérant plusieurs contrôleurs, garantit en moyenne un délai

de récupération plus court que l’approche MA. En revanche, cette solution entraîne
un surcoût de contrôle important. En effet, des requêtes Packet In sont échangées
entre les contrôleurs SDN afin de répartir la charge de travail. Aussi, les gains de
cette approche pourraient s’avérer peu importants par rapport au surcoût engen-
dré. Le nombre de requêtes Packet In est doublé alors que les gains en terme de
latence ne sont que de l’ordre de 5 à 8% par rapport à l’approche MA.
Ainsi, on peut constater que notre approche permet une réelle amélioration de la
transition inter-cellules. En effet, le nombre de requêtes Packet In envoyées par les
stations de base est limité et le délai de récupération est réduit, quel que soit le cas
considéré (UL, NL).
Ces bénéfices sont notamment dus à :
— une estimation plus précise de la durée de vie des règles de flux : si la durée de vie
des règles de flux estimée est inférieure à la durée réelle de communication, une
nouvelle requête Packet In sera envoyée au contrôleur SDN. Aussi, dans certains
cas, plusieurs requêtes pourraient être envoyées au contrôleur pour gérer une
même connexion. Une estimation précise de la durée de connexion permet donc
de réduire ce nombre de requêtes superflues ;
— l’utilisation d’une table d’états pour la gestion des transitions entre cellulaires : les
solutions basées uniquement sur des paramètres temporels pourraient entraîner
des délais liés à un calcul imprécis des durées de connexions (cf. Section 4.5.4).
La prise en compte des informations remontées par les équipements réseau dans
le processus de transition permet donc de réduire le délai de récupération.
4.6.6 Politique de pré-déploiement des règles de flux

Le dernier mécanisme proposé vise à gérer dynamiquement le nombre de règles de
flux devant être pré-déployées (cf. Section 4.5.5). Cette idée n’ayant pas été introduite
dans les travaux existants (cf. Section 4.3), nous avons comparé les performances de
notre approche avec cette politique (P-LAMAP, Policy-LAMAP) et sans cette politique
113
(W-LAMAP, Without policy-LAMAP).

La politique de pré-déploiement proposée est appliquée dans trois cas :
— Oc (Occupied SDN controller) : lorsque le niveau de charge du canal de contrôle
est élevé et le taux d’occupation des tables de flux est bas ;
— Of (Occupied SDN flow tables) : lorsque le niveau de charge du canal de contrôle
est bas et le taux d’occupation des tables de flux est élevé ;
— Ofc (Occupied SDN flow tables and controller) : lorsque le niveau de charge du
canal de contrôle et le taux d’occupation des tables de flux sont élevés.
Considérant notre approche avec et sans politique de pré-déploiement dans ces trois
cas de figure (P-LAMAP-Oc, P-LAMAP-Of, P-LAMAP-Ofc, W-LAMAP-Oc, W-LAMAP-Of, W-
LAMAP-Ofc), nous avons mesuré :
— le taux d’occupation des tables de flux : pour un équipement réseau donné, le
pourcentage moyen d’entrées occupées dans la table des flux par rapport au
nombre total d’entrées disponibles ;
— le délai de récupération (cf. Section 4.6.5) ;
— le surcoût de contrôle (cf. Section 4.6.5) ;
Comme on peut le constater sur la figure 4.6 :
— la politique de pré-déploiement offre les bénéfices attendus. Dans le cas Oc, le

nombre de requêtes Packet In par flux envoyées au contrôleur SDN est réduit
avec l’approche P-LAMAP-Oc. La politique de pré-déploiement garantit donc une
meilleure utilisation du canal de contrôle dans ce cas. Dans le cas Of, le taux
moyen d’occupation des tables de flux est réduit avec l’approche P-LAMAP-Of. La
gestion des tables de flux est donc améliorée. Enfin, dans le cas Ofc, le taux d’occu-
pation des tables de flux et le nombre de requêtes Packet In reçus par le contrôleur
SDN sont tous deux réduits. L’utilisation du canal de contrôle et des tables de flux
est donc améliorée ;
— dans le cas Oc, l’impact de la politique de pré-déploiement sur le délai de récupé-
ration est de 5% en moyenne. De plus, la politique de pré-déploiement réduit le
taux d’occupation des tables de flux. En effet, seules les transitions à la probabi-
lité élevée sont ajoutées à la table des flux. Par conséquent, le nombre de règles
inutilement déployées est réduit ;
114
F IGURE 4.6 – Evaluation de la politique de pré-déploiement proposée
— dans le cas Of, la politique de pré-déploiement permet de réduire de façon impor-

tante le nombre de requêtes Packet In et le délai moyen de récupération. En effet,
avec l’approche W-LAMAP-Of, certaines tables de flux sont saturées. Par consé-
quent, le nombre de requêtes Packet In augmente fortement, induisant un délai
supplémentaire et un surcoût de contrôle ;
— dans le cas Ofc, l’impact de la politique de pré-déploiement sur le délai de récupé-
ration est élevé (30%). En effet, avec l’approche P-LAMAP-Ofc, pour limiter l’utili-
sation du canal de contrôle et des tables de flux, les règles ne sont déployées que
réactivement. Toutefois, ce mécanisme garantit un taux d’occupation plus faible
des tables de flux et permet de diviser par 4 le nombre de requêtes Packet In
transmises dans le pire des cas.
Ainsi, la politique de pré-déploiement offre les bénéfices attendus dans les cas Of
(réduction du taux d’utilisation des tables de flux), Oc (réduction du niveau de charge
du canal de contrôle) et Ofc (réduction du niveau de charge et du taux d’utilisation).
De plus, cette approche fournit des performances quasi équivalentes (Oc : délais de
récupération), voire supérieures (Oc : taux d’occupation, Of : délais de récupération,
115
taux d’occupation) pour les autres indicateurs de performances.

Par conséquent, l’utilisation d’une politique de pré-déploiement des règles de flux
pourrait permettre une meilleure utilisation des tables de flux et du canal de contrôle.
Elle pourrait s’avérer utile, tant pour notre solution, que pour les approches basées sur
la technologie SDN proposées dans la littérature (cf. Section 4.3).
4.6.7 Résumé
Dans cette section, nous avons cherché à comparer les performances de notre so-
lution avec celles des approches introduites dans la littérature (cf. Section 4.6.1). Ceci
nous a permis de confirmer les bénéfices de l’approche proposée en terme d’estima-
tion de la durée de vie des règles de flux (cf. Section 4.6.3). Cette comparaison nous
a également permis de démontrer que notre solution permet de garantir une meilleure
utilisation des ressources à disposition (cf. Section 4.6.4) et une Qualité de Service plus
élevée (cf. Section 4.6.5). Enfin, nous avons pu mettre en avant les bénéfices de la
politique de pré-déploiement proposée (cf. Section 4.6.6), applicable à l’ensemble des
solutions introduites jusqu’ici dans la littérature.
4.7 Discussion : Bénéfices du plan de connaissance pour

la distribution géographique de données
4.7.1 Bénéfices du plan de connaissance
Dans le chapitre 3, nous avons proposé l’intégration d’un plan de connaissance dans
l’architecture de référence C-ITS (cf. Section 3.5). Les outils d’aide à la prise de déci-
sion (intelligence artificielle, données massives) constituent un élément important de ce
plan. En effet, c’est, notamment, grâce à eux que les performances de l’architecture de
communication pourraient être améliorées (cf. Section 3.5.4.1) : plan de gestion, plan
de contrôle et données, plan de sécurité et de respect de la vie privée.
Aussi, dans cette section, nous définissons quelques applications possibles de ces
outils d’aide à la prise de décision dans le cadre de la distribution géographique de don-
nées. Une discussion similaire est proposée dans le chapitre 5 (cf. Section 5.7.1). Une
analyse croisée de ces deux sections (4.7.1, 5.7.1) est proposée en annexe (cf. Annexe
J .). Cette analyse croisée présente les besoins de traitement communs aux différents
116
plans de l’architecture C-ITS et démontre ainsi l’intérêt d’un plan de connaissance glo-
bal.
Dans le cadre d’une distribution géographique des données performante, basée sur
la technologie SDN et sur l’infrastructure cellulaire, le plan de connaissance pourrait
notamment permettre :
— une prédiction performante de la mobilité des véhicules : la gestion pro-active

de la mobilité nécessite une prédiction performante de la mobilité des véhicules.
En effet, plus le système sera en mesure de prédire la mobilité des véhicules de
façon fiable, plus la latence et le taux d’utilisation du canal de contrôle seront
réduits (cf. Section 4.6). Or, l’approche utilisée ici, basée sur des modèles Mar-
koviens, garantit une fiabilité de 70 à 80% [BMO18]. Comme cela a été montré
dans [LS18], l’utilisation de techniques d’intelligence artificielle dans ce contexte
pourrait garantir une fiabilité plus élevée. Ainsi, le plan de connaissance pourrait
garantir une gestion pro-active de la mobilité plus efficace ;
— une estimation précise du niveau de charge des stations de base : l’estima-

tion du niveau de charge des stations de base est utilisée pour calculer la durée
de connexion entre les équipements terminaux et les stations de base (cf. Section
4.5.3.1). Elle permet également une sélection des stations de base réceptrices (cf.
Section 4.5.3.2). Aussi, une estimation précise de ce niveau de charge garantira
des performances élevées pour ces mécanismes. Comme cela a été démontré dans
[ACS18], l’utilisation de techniques d’intelligence artificielle pourrait permettre
d’estimer de façon précise le niveau de charge à tout instant. Ainsi, le plan de
connaissance pourrait garantir une meilleure utilisation des ressources à disposi-
tion (tables de flux, capacité des stations de base) ;
— une distribution de données fiables : la solution introduite dans cette section

permet une distribution géographique des données performante. Néanmoins, un
équipement terminal malicieux pourrait tenter de partager des informations er-
ronées. Aussi, il semble pertinent de contrôler le comportement des équipements
terminaux et de déterminer lesquels sont autorisés à transmettre. Pour ce faire,
l’utilisation de techniques d’intelligence artificielle pourrait offrir une analyse fine
du comportement des équipements terminaux et de la validité des messages trans-
mis [SMZS19]. Ainsi, le plan de connaissance pourrait permettre de garantir que
117
seules des informations fiables sont transmises via le réseau cellulaire ;
— un plan de contrôle plus performant : comme indiqué dans la section 4.4.1, le

fonctionnement des réseaux cellulaires définis logiciellement repose sur un plan
de contrôle distribué. Aussi, le positionnement des contrôleurs SDN, gérant des
zones géographiques spécifiques, constitue un enjeu majeur. En effet, seul un po-
sitionnement efficace des contrôleurs pourra garantir des délais de réponse courts
et des performances élevées. Pour ce faire, l’utilisation de techniques d’intelli-
gence artificielle semble pertinente. En effet, cette approche pourrait permettre
une allocation dynamique et optimale des équipements réseau aux contrôleurs
SDN [DSG19]. Ainsi, le plan de connaissance pourrait garantir un fonctionnement
performant du plan de contrôle.
Ainsi, l’utilisation du plan de connaissance, défini dans la section 3.5.4.1, pourrait

présenter de nombreux bénéfices : une meilleure prédiction de mobilité des terminaux,
une estimation du niveau de charge des stations de base plus précise, un contrôle de la
fiabilité des données et des performances accrues pour le plan de contrôle.
4.7.2 Résumé
Dans cette section, nous avons cherché à identifier les bénéfices que pourrait ap-
porter le plan de connaissance à la distribution géographique de données (cf. Section
4.5). Ainsi, nous avons mis en avant quatre applications du plan de connaissance dans
ce contexte. Tout d’abord, l’utilisation de techniques d’intelligence artificielle pour la
prédiction de mobilité des équipements terminaux (cf. Section 4.5.3.1). Ensuite, l’utili-
sation de ces mêmes techniques pour l’estimation du niveau de charge des stations de
base (cf. Section 4.4.4). Puis, l’application du plan de connaissance au contrôle de la fia-
bilité des données et des équipements terminaux. Enfin, son application à l’amélioration
des performances du plan de contrôle.
4.8 Conclusion
Dans ce chapitre, nous avons introduit notre seconde contribution : une approche
logicielle pour la distribution géographique de données via l’infrastructure cellulaire.
Pour ce faire, nous avons commencé par identifier les principales limites du proto-
cole GeoNet pour cette distribution géographique de données : traitement coûteux et
118
manque de dynamicité. Nous avons également mis en avant les bénéfices de la techno-
logie SDN dans ce contexte. Nous avons, ensuite, ciblé deux éléments devant être pris
en compte pour déployer une solution basée sur SDN dans un environnement mobile.
Il s’agit des échanges entre le contrôleur SDN et les équipements réseau et du taux
d’occupation des tables de flux (cf. Section 4.2.1).
Par la suite, nous nous sommes intéressés aux travaux existants dans la littérature.
Des améliorations ont, en effet, déjà été proposées pour les différentes limites identi-
fiées : traitement des données (cf. Section 4.3.1), distribution des données (cf. Section
4.3.2), utilisation du canal de contrôle (cf. Section 4.3.3) et gestion des tables de flux
(cf. Section 4.3.4). La comparaison de ces travaux nous a permis de mettre en avant
les principales limites des approches proposées jusqu’ici (cf. Section 4.3.5). Les limites
principales sont : le manque de flexibilité dans la gestion de la mobilité, l’imprécision
dans l’estimation de la durée de vie des règles de flux et la non prise en compte du
niveau de charge des stations de base dans la distribution des données.
Afin d’y répondre, nous avons introduit une nouvelle solution devant permettre une
distribution géographique des données performante (cf. Section 4.5.1). Celle-ci se place
dans un contexte particulier (cf. Section 4.4) et s’appuie sur trois évolutions principales.
Tout d’abord, une prise en compte du niveau de charge des stations de base dans l’es-
timation de la durée de vie des connexions entre équipements terminaux et stations de
base (cf. Section 4.5.3.1). Ensuite, une sélection dynamique des stations de base desti-
nataires en fonction de la position des équipements terminaux et du niveau de charge de
ces stations de base (cf. Section 4.5.3.2). Puis, la définition de machines d’états permet-
tant de gérer la mobilité des équipements terminaux de façon plus efficace (cf. Section
4.5.4). Enfin, la proposition d’une politique de pré-déploiement des règles de flux visant
à optimiser l’utilisation du canal de contrôle et tables de flux (cf. Section 4.5.5).
La comparaison de notre solution avec les travaux existants a permis de confirmer les
bénéfices de l’approche proposée en terme d’estimation de la durée de vie des règles de
flux (cf. Section 4.6.3). Elle nous a, également, permis de démontrer que notre solution
permet de garantir une meilleure utilisation des ressources à disposition (cf. Section
4.6.4) et une Qualité de Service plus élevée (cf. Section 4.6.5). Finalement, nous avons
pu mettre en avant les bénéfices de la politique proposée (cf. Section 4.6.6).
Pour finir, nous avons évalué les bénéfices du plan de connaissance (cf. Section
3.5.4.1) dans le cadre de la distribution géographique de données (cf. Section 4.7.1).
119
Ainsi, nous avons pu mettre en avant quatre applications possibles du plan de connais-
sance. La première d’entre elles est la prédiction de mobilité des équipements termi-
naux. La seconde est l’estimation du niveau de charge des stations de base. La troisième
est le contrôle de la fiabilité des équipements terminaux. La dernière concerne l’amélio-
ration des performances du plan de contrôle.
Pour garantir le bon fonctionnement de la solution proposée dans ce chapitre, la
sécurisation de l’architecture de référence C-ITS est essentielle. Aussi, dans le chapitre
suivant, nous introduisons une solution, basée sur la Blockchain, devant notamment
permettre d’assurer la sécurisation des interfaces SDN.
120
Chapitre 5
Une sécurisation des réseaux SD-IoV

s’appuyant sur la Blockchain
5.1 Introduction
Dans le chapitre 3, nous avons proposé différentes améliorations de l’architecture
de référence C-ITS (cf. Section 3.5). Celles-ci doivent rendre possible l’avènement de
l’IoV et le déploiement de l’ensemble des applications C-ITS (cf. Section 3.5). L’une des
importantes évolutions considérées est l’intégration de la technologie SDN (cf. Section
3.3.1.1) dans le plan de contrôle et de données de l’architecture de référence C-ITS.
Cette technologie pourrait garantir une gestion plus efficace de la mobilité des équipe-
ments terminaux et de meilleures performances (débit, latence, perte de paquets) pour
la distribution géographique de données (cf. Chapitre 4). De plus, comme cela a été
prouvé dans de nombreux travaux, la technologie SDN pourrait également permettre
l’interopérabilité des réseaux de communication hétérogènes (cf. Section 3.3.1.3).
Néanmoins, comme cela a été indiqué dans le chapitre 3, pour garantir la fiabilité
et la disponibilité des applications C-ITS, la sécurisation de l’architecture de référence
C-ITS, et notamment du plan de contrôle et de données, est primordiale (cf. Section
3.5.3.1). SDN jouant un rôle important dans le fonctionnement de ce plan, il est es-
sentiel de garantir la sécurité de cette technologie. En particulier, la sécurisation des
échanges ente les différents éléments SDN (applications, contrôleurs, équipements ré-
seau) doit être considérée [DKC+ 17, KIAM17].
C’est pourquoi, dans ce chapitre, nous introduisons notre troisième contribution :
une solution permettant de sécuriser les interfaces SD-IoV (sud, est/ouest, nord). L’ap-
proche proposée s’appuie sur une technologie dont nous avons également proposé l’in-
tégration dans l’architecture de référence C-ITS : la Blockchain (cf. Section 3.3.4.1).
Dans ce chapitre, nous commençons par justifier la nécessité de sécuriser les inter-
faces de communication SD-IoV et mettre en avant les avantages de la Blockchain dans
121
5. Une sécurisation des réseaux SD-IoV s’appuyant sur la Blockchain
ce contexte (cf. Section 5.2.1). Par la suite, nous présentons les solutions existantes
visant à sécuriser l’architecture SD-IoV, notamment celles basées sur la Blockchain, et
identifions leurs principales limites (cf. Section 5.3). Nous proposons, ensuite, une nou-
velle solution, basée sur la Blockchain, devant permettre la sécurisation (chiffrement,
authentification, contrôle d’accès) des interfaces SD-IoV (cf. Section 5.4). Puis, nous
évaluons les performances (cf. Section 5.5) et la faisabilité (cf. Section 5.6.1) de l’ap-
proche proposée. Pour finir, nous discutons de l’intérêt que pourrait présenter le plan
de connaissance de l’architecture de communication C-ITS (cf. Section 3.5.4.1) dans ce
contexte (cf. Section 5.7.1).
5.2 Motivations
5.2.1 Présentation
La technologie SDN apparaît aujourd’hui comme un élément essentiel des futurs
réseaux de communication véhiculaires [MCK19b, BC15, SMAC16, JHN+ 16] et des ré-
seaux cellulaires de 5ème génération. Les bénéfices apportés par cette technologie sont
nombreux : programmabilité, centralisation, flexiblité, etc. Ainsi, elle pourrait permettre
de garantir une gestion optimale et adaptative des ressources quelles que soient les
conditions (mobilité, hétérogénéité, variation de densité) [YBSS17, ZFY+ 18, BFG+ 17].
L’approche SD-IoV constitue une réelle évolution dans la façon de penser et de
concevoir les réseaux de communication véhiculaires (cf. Section 3.3.1.1). En effet, cette
technologie repose sur l’idée de découpler le plan de contrôle et de données du réseau
et d’intégrer un nouvel élément, le contrôleur SDN. Ainsi, l’architecture de communi-
cation SD-IoV est composée de trois plans principaux : données, contrôle, applicatif.
Or les interfaces de communication entre ces différents plans (sud, nord, est/ouest :
cf. Section 3.3.1.2), sujettes à de nombreux vulnérabilités, pourraient être vecteurs de
différentes attaques [SHNS15] :
— déni de service : cette attaque pourrait principalement affecter les interfaces sud
et est/ouest [AWG+ 20]. De part la centralisation introduite par l’architecture SDN,
un attaquant pourrait tenter de prendre le contrôle d’un ensemble d’équipements
réseau pour transmettre un nombre important de requêtes (Packet In) au contrô-
leur SDN. Ceci pourrait entraîner une saturation du contrôleur SDN ou du canal
de contrôle. Pour lutter contre ce genre d’attaques, la distribution physique du
122
plan de contrôle (multiples contrôleurs SDN logiquement centralisés) et la sur-

veillance des échanges entre équipements réseau et contrôleurs SDN pourraient
être considérées [DZ16]. Dans le cas d’une architecture distribuée, les interfaces
est/ouest pourraient également être utilisées par un contrôleur malveillant pour
mener des attaques de déni de service. L’authentification des contrôleurs et le
contrôle d’accès pourraient être considérés pour lutter contre ce genre d’attaques.
Enfin, ce même contrôleur malveillant pourrait mener une attaque contre un équi-
pement réseau. Il pourrait notamment chercher à surcharger la table des flux de
cet équipement réseau. L’authentification et le contrôle d’accès du contrôleur SDN,
associés à une gestion efficace de la durée de vie des règles de flux, pourraient être
mis en place pour résoudre ce problème. Ainsi, associés à une distribution du plan
de contrôle et à une gestion efficace des tables de flux, l’authentification et le
contrôle d’accès des équipements réseau pourraient permettre de lutter contre les
attaques de déni de service ;
— analyse du réseau : cette attaque est envisageable pour l’ensemble des interfaces
(sud, nord, est/ouest). Elle consiste à récupérer des informations concernant l’état
du réseau : topologie, bande passante, délais, etc. On peut distinguer deux caté-
gories :
• man-in-the-middle (MITM) : les contrôleurs SDN, les équipements réseau

et les applications ne sont pas nécessairement authentifiés. Une attaque de
type MITM est donc possible. Ainsi, un intrus pourrait aisément récupérer
des informations concernant l’état du réseau. Au niveau de l’interface sud,
ces informations pourraient correspondre à des informations remontées au
contrôleurs SDN (délais, requêtes, etc.) ou des règles de flux déployées par
les contrôleurs SDN. Au niveau de l’interface est/ouest, il pourrait s’agir
de messages échangés entre des contrôleurs gérant des domaines différents
(routage, topologie). Enfin, au niveau de l’interface nord, il pourrait s’agir
d’informations concernant l’état du réseau remontées par le contrôleur SDN
ou des demandes de ressources émises par les applications. Par conséquent,
ce type d’attaque pourrait permettre à une entité malveillante de disposer
de nombreuses informations : canaux de communication, topologie, vulné-
rabilités, etc. Aussi, la mise en place de mécanismes d’authentification et de
123
chiffrement (intégrité, confidentialité) des données est essentielle ;

• élément compromis : les contrôleurs SDN et applications SDN, et les équi-
pements réseau dans une moindre mesure, sont en mesure de récupérer un
nombre important d’informations concernant l’état du réseau : topologie,
bande passante, etc. Par conséquent, un équipement réseau (interface sud),
un contrôleur SDN (interfaces sud et est/ouest) ou une application SDN (in-
terface nord) malveillants pourraient être en mesure de mener une impor-
tante attaque de reconnaissance. Aussi, il est essentiel d’assurer une authen-
tification et un contrôle d’accès efficaces des contrôleurs SDN, des équipe-
ments réseaux et des applications SDN afin de cloisonner l’accès aux données
et de limiter le potentiel de l’attaque de reconnaissance ;
— modification du réseau : cette attaque est envisageable pour l’ensemble des inter-
faces (sud, nord, est/ouest). Elle consiste à modifier le comportement du réseau :
remontées d’informations, règles de flux, demandes de ressources, etc. On peut
classifier ce type d’attaques en deux catégories :
• man-in-the-middle : un élément non autorisé, au delà de mener une attaque

de reconnaissance, pourrait chercher à modifier le comportement du réseau.
Ainsi, un attaquant pourrait modifier les informations remontées par les équi-
pements réseau (délais, bande passante disponible, etc.) ou transmises entre
contrôleurs SDN (interface est/ouest). Ceci pourrait entraîner des prises de
décision erronées de la part du plan de contrôle. L’attaquant pourrait égale-
ment supprimer les requêtes Packet In transmises par un/des équipement(s)
réseau. De même, un attaquant pourrait modifier les règles de flux transmises
par le contrôleur SDN et ainsi détourner le trafic (interface sud). Il pourrait
aussi modifier les autorisations des applications (interface nord). Enfin, un
attaquant pourrait modifier les demandes de ressources transmises par les
applications SDN. Pour se prémunir contre ces attaques, l’authentification et
le chiffrement (intégrité, confidentialité) paraissent essentiels ;
• élément compromis : un élément compromis pourrait également chercher
à modifier le comportement du réseau : introduction de règles conflictuelles,
remontées d’informations erronées, modification de droits, etc. Pour limiter
les risques liés à ce genre d’attaques, au delà de l’authentification et du chif-
124
frement, la définition de politiques d’accès aux ressources est importante

[SHNS15]. La définition de mécanismes plus intelligents visant à analyser
le comportement des éléments est également possible [LS16].
Ainsi, une entité malveillante extérieure, ou un élément SDN compromis (applica-

tion, contrôleur, équipement réseau), pourrait utiliser les interfaces SD-IoV (nord, sud,
est/ouest) pour mener différents types d’attaques. Il pourrait, notamment, s’agir d’une
attaque de reconnaissance, d’une modification du fonctionnement du réseau ou d’une
attaque de déni de service. La sécurisation de ces interfaces apparaît donc comme une
nécessité. En effet, sans cette sécurisation, le bon fonctionnement des réseaux véhicu-
laires et des applications C-ITS ne pourra être garanti [AWG+ 20, AHZI+ 20].
Pour permettre cette sécurisation, le chiffrement des données, une authentification
forte et une politique de contrôle d’accès efficace sont essentiels. En effet, à condition
que la configuration des interfaces soit fiable [SHNS15], le chiffrement et l’authenti-
fication pourraient permettre de se prémunir contre les attaques de type MITM. De
plus, associés à une politique de contrôle d’accès, ils pourraient permettre de limiter les
risques (confinement des attaques) liés aux éléments compromis ainsi qu’aux attaques
de déni de service.
Pour concevoir de tels mécanismes, garantissant authentification, chiffrement et
contrôle d’accès, des approches traditionnelles, utilisant une infrastructure centralisée,
pourraient être considérées. En effet, hors de l’environnement véhiculaire, des solu-
tions basées sur des infrastructures à clé publiques (PKI) et des infrastructures de ges-
tion de privilèges (Privilege Management Infrastructure, PMI) ont été proposées tant
pour l’authentification et le chiffrement que pour le contrôle d’accès des éléments SDN
[ASV17, WLC+ 17, MMF+ 19]. De plus, l’utilisation du protocole Transport Layer Security
(TLS) peut être considérée pour sécuriser l’ensemble des interfaces SD-IoV [SHNS15].
Néanmoins, comme nous l’avons expliqué dans le chapitre 3, la gestion (révocation)
des certificats représente un frein au déploiement de ces approches. De plus, ces solu-
tions centralisées pourraient présenter différentes limites dans l’environnement véhicu-
laire. En effet, de part la forte mobilité des équipements terminaux, le nombre important
de noeuds, et l’importance des applications associées aux communications véhiculaires
(sécurité routière), les questions de passage à l’échelle, de garantie de sécurité et d’éta-
blissement de confiance sont essentielles (cf. Section 3.2.1).
Face à ce constat, de nombreux travaux (cf. Section 5.3) ont proposé d’utiliser une
125
nouvelle technologie pour sécuriser les interfaces SD-IoV : la Blockchain [MCK20b].

En effet, comme nous l’avons expliqué dans la section 3.3.4.3, cette technologie, cor-
rectement utilisée, pourrait garantir un passage à l’échelle important et un niveau de
sécurité et de confiance élevé. La Blockchain apparaît donc comme une solution perti-
nente pour sécuriser l’architecture SD-IoV. Comme noté dans [LMLA20], l’application
de la Blockchain aux réseaux SDN pourrait même être plus large et permettre de ré-
soudre les problématiques liées au coût de déploiement et d’entretien, à la latence et à
la protection de la vie privée.
Toutefois, la comparaison des travaux existants (cf. Section 5.3.4), démontre que
ces approches ne garantissent pas la sécurisation de l’ensemble des interfaces (sud,
est/ouest, nord) et ne prennent pas en compte l’ensemble des problématiques (passage
à l’échelle, sécurité renforcée, établissement de confiance) que nous avons identifiées.
C’est pourquoi, dans la suite de ce chapitre, une nouvelle approche sera introduite.
Celle ci s’appuie sur une architecture Blockchain innovante et des mécanismes permet-
tant la sécurisation des interfaces SD-IoV (cf. Section 5.4). Considérant l’architecture
de communication C-ITS dans sa globalité, nous nous proposons également d’expli-
quer l’intérêt du plan de connaissance (cf. Section 3.5.4.1) dans ce contexte (cf. Section
5.7.1).
5.2.2 Résumé
Notre objectif est de sécuriser les interface de communications de l’architecture SD-

IoV. Aussi, dans cette section, nous identifions les principaux vecteurs d’attaques aux-
quels sont confrontées ces interfaces de communication (sud, nord, est/ouest). Ces at-
taques pourraient, notamment, correspondre à un accès non autorisé à des données ou
une modification non autorisée de ces mêmes données ou une attaque de déni de ser-
vice. La définition de mécanismes de chiffrement, d’authentification et de contrôle d’ac-
cès efficaces pourrait permettre de protéger l’architecture SD-IoV contre ces attaques.
Aussi, dans cette section, nous mettons également en avant la Blockchain. Cette tech-
nologie pourrait, en effet, garantir le passage à l’échelle, l’établissement de confiance et
un niveau de sécurité élevé pour le plan de sécurité (cf. Section 3.3.4.3).
126
5.3 Solutions existantes

Comme nous venons de le voir, les interfaces (sud, nord, est/ouest) de l’architecture
SD-IoV pourraient être confrontées à de nombreuses attaques (cf. Section 5.2.1). Pour
se prémunir contre ces attaques, la définition de mécanismes de chiffrement, d’authen-
tification et de contrôle d’accès efficaces est nécessaire. Ces mécanismes pourraient no-
tamment s’appuyer sur une technologie innovante : la Blockchain (cf. Section 3.3.4.1).
En effet, cette technologie, correctement utilisée, pourrait permettre de garantir le pas-
sage à l’échelle, la sécurité et la confiance (cf. Section 3.3.4.3).
Aussi, dans l’environnement véhiculaire, de nombreux travaux de recherche se sont
déjà intéressés à la définition de mécanismes de chiffrement, d’authentification et de
contrôle d’accès basés sur la Blockchain. Les évolutions proposées, présentées dans cette
section, peuvent avoir différents objectifs. Tout d’abord, la sécurisation de l’interface
sud SD-IoV (cf. Section 5.3.1). Ensuite, la sécurisation de l’interface est/ouest SD-IoV
(cf. Section 5.3.2). Enfin, la sécurisation de l’interface nord SD-IoV (cf. Section 5.3.3).
Toutefois, l’étude des travaux existants (cf. Section 3.4.4) démontre que certains points
doivent encore être considérés pour répondre aux problématiques identifiées dans la
section précédente.
5.3.1 Sécurisation de l’interface sud

De part le nombre important d’équipements terminaux et leur forte mobilité, la sé-
curisation de cette interface sud constitue un enjeu majeur dans les réseaux SD-IoV.
Aussi, de nombreux travaux se sont intéressés à la sécurisation de cette interface.
Certains de ces travaux se concentrent uniquement sur l’authentification et le chiffre-
ment des données transmises par les véhicules [MNA+ 18, AK17, LWQ+ 19]. Ainsi dans
les solutions proposées par les auteurs de [MNA+ 18, LWQ+ 19], le registre Blockchain
fait office d’Infrastructure à Clé Publique décentralisée. Il garantit l’enregistrement, la
révocation et le stockage des identités des véhicules. Cette approche permet, par consé-
quent, d’assurer la sécurisation des échanges tout en garantissant un passage à l’échelle
plus important. Allant plus loin, les auteurs de [AK17] proposent d’utiliser la Block-
chain pour le transfert de l’ensemble des données transmises par les véhicules. Ainsi,
cette approche garantit les fonctions de chiffrement et d’authentification en utilisant
exclusivement l’approche Blockchain.
127
D’autres travaux ajoutent le contrôle d’accès à l’authentification et au chiffrement

des données transmises par les véhicules [ZWZ19, XDYW19, LWQL18]. Ainsi, dans ces
solutions, en plus d’utiliser la Blockchain comme Infrastructure à Clé Publique, un in-
dice de confiance est associé à chaque véhicule. Pour calculer la valeur de cet indice,
des mécanismes de consensus spécifiques sont proposés. Ces mécanismes visent, notam-
ment, à évaluer le niveau de confiance à accorder à un véhicule en fonction des actions
passées de ce véhicule : transmission d’informations erronées, détournement du trafic,
etc. Par conséquent, cette solution permet de s’assurer de l’authentification et du chif-
frement des données transmises par les véhicules mais également de limiter l’accès au
réseau SD-IoV. En effet, seuls des véhicules disposant d’un indice de confiance suffisant
sont autorisés à accéder au réseau.
Au contraire, la solution proposée dans [BGR19] s’intéresse au chiffrement, à l’au-
thentification et au contrôle d’accès des données transmises par le contrôleur SDN. Pour
ce faire, les auteurs proposent d’inter-connecter le contrôleur SDN à un registre Block-
chain. Ainsi, lorsque ce contrôleur SDN transmet une règle à un équipement réseau, il
l’écrit également dans le registre Blockchain qu’il est le seul à pouvoir modifier. Grâce à
cela, quand un équipement réseau reçoit une règle, il est en mesure de vérifier qu’elle
est bien présente dans le registre Blockchain. Il sait donc si elle a été on non émise par
le contrôleur SDN. Le système proposé permet également de s’assurer que l’équipement
réseau ne peut accéder qu’aux règles de flux qui lui sont destinées. Pour ce faire l’au-
thentification de ces équipements réseau est mise en place. Ainsi, cette approche permet
de s’assurer que les règles de flux reçues par des équipements réseau ont bien été trans-
mises par un contrôleur SDN, qu’elles n’ont pas été modifiées et que seuls les éléments
autorisés peuvent les lire.
Allant plus loin, les auteurs de [SSJP17] proposent une solution globale, tant pour
l’authentification et le chiffrement que pour le contrôle d’accès des équipements ré-
seau et des contrôleurs SDN. Pour ce faire, ils utilisent la Blockchain comme interface
sud SD-IoV, remplaçant le protocole OpenFlow. Ainsi, chaque élément (contrôleur SDN,
équipement réseau) ajoute à la Blockchain les données qu’il souhaite transmettre (règles
de flux, feedback, etc.) en utilisant ses identifiants uniques. Ceci garantit l’authentifica-
tion et le chiffrement des données. De plus, seuls les contrôleurs appartenant au réseau
SD-IoV sont en mesure d’accéder aux informations remontées par les équipements ré-
seau. De même, les équipements réseau ne peuvent accéder qu’aux règles de flux qui
128
les concernent. Par conséquent, l’authentification, le chiffrement et le contrôle d’accès

sont assurés pour l’interface sud dans cette approche.
Ainsi, certains travaux se concentrent, spécifiquement, sur le transfert de règles de
flux (contrôleurs SDN) [BGR19] ou la remontée des données (véhicules), en propo-
sant l’authentification et le chiffrement [MNA+ 18, AK17, LWQ+ 19], ou, également, le
contrôle d’accès [ZWZ19, XDYW19]. Par conséquent, ces solutions ne permettent pas de
garantir des solutions sécurisées bi-directionnelles pour l’interface sud SD-IoV. Des at-
taques sont donc encore possibles. Seule l’approche introduite dans [SSJP17] propose
une solution globale sécurisant l’ensemble des messages échangés entre équipements
réseau et contrôleurs SDN. Néanmoins, on peut noter une limite importante à cette ap-
proche. En basant l’ensemble des échanges sur la Blockchain, la solution proposée par
les auteurs de [SSJP17] impliquerait une évolution importante de l’interface sud SD-IoV
et le remplacement des protocoles actuellement utilisés, en particulier OpenFlow.
5.3.2 Sécurisation de l’interface est/ouest

L’architecture SD-IoV devrait s’appuyer sur un plan de contrôle distribué [JHN+ 16].
En effet, ceci garantirait un meilleur passage à l’échelle et une résilience plus impor-
tante. Aussi, l’interface est/ouest doit être sécurisée.
Toutefois, les solutions proposées jusqu’ici ne considèrent pas la sécurisation des
interfaces existantes mais bien une évolution du fonctionnement du plan de contrôle
SD-IoV. Par exemple, les auteurs de [BGR19] proposent de connecter l’ensemble des
contrôleurs SDN à un registre Blockchain. Ainsi, l’ensemble des règles de flux déployées
par chaque contrôleur SDN sont également enregistrées dans le registre Blockchain.
Ceci permet à chacun de connaître l’état du réseau dans sa globalité ainsi que les res-
sources actuellement utilisées. Cette approche permet, par conséquent, d’assurer le chif-
frement, l’authentification et le contrôle d’accès de l’interface est/ouest. Les auteurs de
[SSJP17, ZYY19] proposent, eux, de remplacer le plan de contrôle SDN par des ap-
plications déployées dans la Blockchain (smart contract). Cette solution garantirait des
échanges sécurisés entre contrôleurs SDN ainsi qu’un contrôle d’accès (seuls les contrô-
leurs appartenant au réseau peuvent accéder aux données).
Néanmoins, la mise en pratique de ces approches [BGR19, SSJP17, ZYY19] néces-
siterait une évolution importante dans la façon de penser et de déployer les réseaux
SDN. En effet, l’évolution de l’interface est/ouest [BGR19], voire même du plan de
129
contrôle dans sa globalité [SSJP17, ZYY19], devrait être considéré. De plus, la faisa-
bilité de solutions nécessitant le déploiement de contrôleurs SDN comme applications
Blockchain devrait être considérée. Ainsi, il pourrait être intéressant de définir pour l’in-
terface est/ouest des mécanismes, basés sur la Blockchain, permettant la sécurisation
de l’architecture SD-IoV dans sa forme actuelle.
5.3.3 Sécurisation de l’interface nord

Comme expliqué dans la section 5.2.1, la définition de mécanismes de chiffrement,
d’authentification et de contrôle d’accès au niveau de l’interface nord est essentielle.
En effet, un contrôleur ou une application malveillants pourraient impacter le fonction-
nement du réseau : demande d’un nombre trop important de ressources, remontées
d’informations erronées, etc. Néanmoins, jusqu’ici, aucune solution basée sur la Block-
chain n’a été proposée pour sécuriser cette interface, tant dans l’environnement SD-IoV
que dans l’environnement SDN au sens large.
Hors de la technologie Blockchain, certaines approches présentes dans la littéra-
ture visent à sécuriser cette interface [ABA17, IKLK17, SKS14, BKT15]. Ainsi, dans
[ABA17, IKLK17, SKS14] sont introduites des solutions devant permettre d’authentifier
les applications SDN, de gérer leurs droits d’accès (lecture, écriture, notification et appel
système) ainsi que le niveau de confiance qui leur est accordé. S’intéressant également
à l’idée de confiance, les auteurs de [BKT15] proposent d’utiliser différents contrôleurs
pour vérifier les demandes de ressources transmises par les applications SDN. Ainsi, les
demandes de configuration réseau générées par ces différents contrôleurs sont compa-
rées et contrôlées. Si elles sont similaires et fiables, elles sont déployées. Dans le cas
contraire, la demande de l’application SDN est rejetée.
Néanmoins, ces approches considèrent un plan de contrôle basé sur un seul contrô-
leur. Seule l’approche proposée dans [BKT15] utilise plusieurs contrôleurs pour véri-
fier les requêtes transmises par la couche applicative. De plus, l’idée d’authentifier les
contrôleurs n’est pas évoquée dans ces travaux. Or, dans le contexte véhiculaire, un plan
de contrôle distribué est nécessaire et la sécurisation des communications primordiale.
5.3.4 Comparaison
De nombreux travaux ont proposé l’utilisation de la Blockchain pour sécuriser les
interfaces SD-IoV. Les travaux existants, portant essentiellement sur l’interface sud (cf.
130
Section 5.3.1) et l’interface est/ouest (cf. Section 5.3.2), peuvent être classées en diffé-
rentes catégories (cf. Tableau 5.1) :
— ceux qui se concentrent sur l’interface sud :

• les auteurs de [MNA+ 18, AK17, LWQ+ 19] proposent de chiffrer et authenti-
fier les messages émis par les équipements terminaux (uni-directionnel) ;
• les auteurs de [ZWZ19, XDYW19, LWQL18] proposent de chiffrer, authen-
tifier et contrôler l’accès des messages émis par les équipements terminaux
(uni-directionnel) ;
— ceux qui se concentrent sur l’interface est/ouest : les auteurs de [ZYY19] pro-
posent de chiffrer, authentifier et contrôler l’accès des messages échangés entre
contrôleurs SDN ;
— ceux qui se concentrent sur les interfaces sud et est/ouest :
• les auteurs de [BGR19] proposent la définition d’un mécanisme d’authenti-
fication et de chiffrement des messages émis par les équipements terminaux
(uni-directionnel) ainsi que de ceux échangés entre contrôleurs SDN ;
• les auteurs de [SSJP17] proposent de chiffrer, authentifier et contrôler d’ac-
cès de l’ensemble des messages échangés entre contrôleurs SDN et entre
contrôleurs SDN et équipements terminaux (bi-directionnel).
Ainsi, les solutions existantes permettent d’assurer la sécurisation de l’interface sud

et de l’interface est/ouest de l’architecture SD-IoV (cf. Tableau 5.1). De plus, l’introduc-
tion de la Blockchain dans l’architecture de communication véhiculaire pourrait per-
mettre de répondre à deux problématiques identifiées (cf. Section 3.2.1). La sécurité
est accrue grâce à la suppression du point d’attaque unique que constitue l’autorité de
certification dans les approches classiques. La confiance est renforcée grâce à la véri-
fication transparente des données par un nombre important de noeuds. Néanmoins,
pour offrir une solution complète prenant en compte l’ensemble des vecteurs d’attaques
et des problématiques identifiés (cf. Section 5.2.1), certains points doivent encore être
considérés :
— la sécurisation de l’interface nord : aucune des solutions proposées jusqu’ici ne
considère la sécurisation des échanges entre contrôleurs SDN et applications. Or,
comme nous l’avons noté dans la section 5.2.1, la sécurisation de cette interface
131
Tableau 5.1 – Comparaison des approches utilisant la Blockchain pour la sécurisation

des interfaces SD-IoV
Int.a sud Int.a est/ouest Int.a nord

Approches
Chif.b Auth.c ACd Chif.b Auth.c ACd Chif.b Auth.c ACd
+ e e
[MNA 18] Uni Uni Non Non Non Non Non Non Non
e e
[AK17] Uni Uni Non Non Non Non Non Non Non
+ e e
[LWQ 19] Uni Uni Non Non Non Non Non Non Non
e e e
[ZWZ19] Uni Uni Uni Non Non Non Non Non Non
[XDYW19] Unie Unie Unie Non Non Non Non Non Non
e e e
[LWQL18] Uni Uni Uni Non Non Non Non Non Non
e e e
[BGR19] Uni Uni Uni Oui Oui Oui Non Non Non
[SSJP17] Oui Oui Oui Oui Oui Oui Non Non Non
[ZYY19] Non Non Non Oui Oui Oui Non Non Non
Proposition Oui Oui Oui Oui Oui Oui Oui Oui Oui
a b c d
Int. : Interface, Chif. : Chiffrement, Auth. : Authentification, AC : Contrôle d’accès
d
Uni : Unilatéral
est essentielle. En effet, des attaques de type MITM ou un élément malveillant

pourraient fortement perturber le fonctionnement du réseau. Par conséquent, la
prise en compte de cette interface est nécessaire lors de la définition d’une solution
sécurisant les communications SD-IoV ;
— la définition d’une solution non disruptive pour l’interface est/ouest : les

solutions introduites dans la littérature pour la sécurisation de cette interface
proposent de déployer les contrôleurs SDN sous forme d’applications Blockchain
[BGR19, SSJP17]. Par conséquent, ces approches impliquent une modification im-
portante de l’architecture de communication SD-IoV. Or, le développement et le
déploiement de telles approches nécessiteraient un important travail de standar-
disation, difficilement concevable dans l’immédiat. Il semble donc pertinent de
définir une solution garantissant la sécurité de l’interface est/ouest et s’intégrant
dans l’architecture SD-IoV actuelle ;
— le passage à l’échelle : l’ensemble des solutions proposées jusqu’ici s’appuient sur

un réseau Blockchain unique, interconnectant l’ensemble des équipements termi-
naux, équipements réseau, contrôleurs SDN et applications. Or, considérant qu’à
l’avenir la majorité des véhicules en circulation pourraient devenir connectés, la
132
viabilité d’un tel système est peu probable. En effet, comme cela a été démon-
tré dans [NQATN18], la gestion d’un nombre trop important de requêtes pourrait
entraîner une dégradation des performances, notamment en terme de latence.
L’authentification et le contrôle d’accès pourraient donc devenir impossible. Par
conséquent, cette approche, basée sur une seule architecture de communication,
pourrait présenter des limites en terme de passage à l’échelle. La définition d’une
nouvelle architecture, augmentant le niveau de distribution, pourrait donc être
nécessaire.
Aussi, pour offrir une solution basée sur la Blockchain garantissant la sécurité de
l’ensemble des interfaces SD-IoV, la définition d’une nouvelle approche est essentielle.
Les questions de passage à l’échelle et de sécurisation des interfaces est/ouest et nord
doivent notamment être considérées. C’est pourquoi, dans la suite de ce chapitre, une
nouvelle solution est proposée. Celle ci s’appuie sur une nouvelle architecture Block-
chain (cf. Section 5.4.2) ainsi que sur des mécanismes d’authentification (cf. Section
5.4.3.2) et de contrôle d’accès (cf. Section 5.4.3.3) adaptés à l’environnement SD-IoV.
L’évaluation de la solution proposée tend à démontrer ses avantages comparé aux solu-
tions existantes (cf. Section 5.5) ainsi que sa faisabilité (cf. Section 5.6.1).
5.3.5 Résumé
Dans cette section 5.3, les améliorations proposées au niveau des différentes inter-
faces SD-IoV sont introduites : interface sud (cf. Section 5.3.1), interface est/ouest (cf.
Section 5.3.2) et interface nord (cf. Section 5.3.3). Par la suite (cf. Section 5.3.4), les
solutions existantes sont comparées et leurs limites identifiées. Il s’agit, notamment, de
l’absence de sécurisation pour l’interface nord, de la non existence d’une solution non
disruptive pour l’interface est/ouest et du passage à l’échelle.
5.4 Une sécurisation des réseaux SD-IoV s’appuyant sur

la Blockchain
Dans cette section nous introduisons une nouvelle solution, basée sur la Blockchain,
devant permettre de sécuriser les interfaces SD-IoV. Nous commençons par définir les
objectifs (cf. Section 5.4.1). Par la suite, nous proposons une nouvelle architecture Blo-
ckchain devant garantir le passage à l’échelle (cf. Section 5.4.2). Enfin, nous introdui-
133
sons des mécanismes d’authentification (cf. Section 5.4.3.2) et de contrôle d’accès (cf.
Section 5.4.3.3) pour les éléments SD-IoV.
5.4.1 Objectifs
Considérant une architecture SD-IoV basée sur un plan de contrôle distribué (cf.
Figure 4.1), et les limites identifiées (cf. Section 5.2.1), notre objectif est de concevoir
une approche basée sur la Blockchain pour la sécurisation des interfaces SD-IoV. La
solution proposée doit présenter différentes caractéristiques :
— passage à l’échelle : l’architecture Blockchain sous jacente doit permettre l’au-
thentification et le contrôle d’accès d’un nombre important d’éléments. En effet,
les réseaux SD-IoV pourraient être amenés à gérer un réseau composé de plu-
sieurs centaines de millions d’éléments : véhicules, piétons, équipements réseau,
contrôleurs SDN, applications. Pour garantir ce passage à l’échelle, nous propo-
sons une nouvelle architecture, composée de plusieurs sous-réseaux Blockchain
interconnectés (cf. Section 5.4.2) ;
— interopérabilité avec l’architecture SD-IoV : la solution Blockchain proposée
doit pouvoir s’intégrer dans l’architecture SD-IoV actuelle sans nécessiter des évo-
lutions importantes des interfaces. Pour ce faire, nous proposons une implémenta-
tion du protocole TLS s’appuyant sur un registre Blockchain et non une infrastruc-
ture à clé publique standard (cf. Section 5.4.3.2). En effet, comme l’ont démontré
les auteurs de [KKM19], utiliser la Blockchain pour établir l’authenticité des certi-
ficats pourrait permettre de réduire la latence liée à l’authentification ainsi que le
coût de maintenance. De plus, TLS est une solution adoptée par certains contrô-
leurs SDN pour l’interface sud [KKM19]. TLS pourrait également être utilisé pour
les interfaces est/ouest et nord [LLLO16]. Enfin, TLS est supporté par les réseaux
d’accès 5G [ZYCW20] et ITS-G5 [RCCF19]. Par conséquent, la solution proposée
sera intégrable dans l’architecture actuelle et adaptée aux solutions de sécurité
retenues dans l’environnement SD-IoV ;
— sécurisation de l’ensemble des interfaces : la solution Blockchain proposée doit
permettre le chiffrement, l’authentification et le contrôle d’accès au niveau de
l’ensemble des interfaces SD-IoV. Sans cela, la sécurité de l’architecture de com-
munication ne pourra être assurée (cf. Section 5.2.1). Aussi, dans notre approche,
l’authentification (cf. Section 5.4.3.2) et le contrôle d’accès (cf. Section 5.4.3.3)
134
sont mis en place pour l’ensemble des noeuds. De plus, l’interopérabilité entre la
solution proposée et TLS permet de garantir le chiffrement des données ;
— faisabilité : le déploiement de la solution Blockchain proposée doit être réaliste.

Sans cela, la sécurisation de l’architecture SD-IoV ne pourra être garantie. Le dé-
ploiement théorique de notre approche doit donc être étudié (cf. Section 5.6.1).
5.4.2 Architecture Blockchain proposée

Les solutions existantes ne considère qu’un seul réseau Blockchain, global, déployé à
l’échelle de la planète (cf. Section 5.3). Les informations permettant l’authentification et
le contrôle d’accès des éléments SD-IoV sont donc stockées et contrôlées par les noeuds
Blockchain appartenant à ce réseau global. Par conséquent, pour chaque initiation d’une
communication entre deux éléments SD-IoV (nord, sud, est/ouest), et chaque mise à
jour des informations stockées (certificat, privilèges, etc.), une requête est soumise à
ce réseau. Considérant un déploiement à large échelle des applications C-ITS, une telle
architecture semble peu viable. En effet, le stockage d’une quantité trop importante de
données, et la gestion d’un nombre trop important de requêtes, pourraient entraîner
une détérioration des performances du réseau Blockchain [NQATN18]. Or, les réseaux
SD-IoV pourraient être amenés à gérer plusieurs centaines de millions d’éléments.
De plus, les équipements de bord de route et les contrôleurs SDN sont attachés à des
zones géographiques particulières [MCK19b] : pays, ville, quartier, rue, etc. De même,
les équipements terminaux (véhicules, piétons, etc.) ne se déplacent généralement que
dans des zones géographiques limitées. Ainsi, seules les applications SD-IoV, pouvant
gérer le réseau de manière globale, ne sont pas directement dépendantes d’une posi-
tion géographique. Par conséquent, il semble peu pertinent de stocker les informations
concernant les équipements terminaux, équipements de bord de route et contrôleurs
SDN (certificats, privilèges, révocation, etc.) dans l’ensemble du réseau Blockchain. En
effet, ces informations ne seront utilisées que par un nombre limité de noeuds Blo-
ckchain. Il s’agit des noeuds auxquels les éléments SD-IoV enverront des requêtes, et
donc des noeuds présents dans la même zone géographique que ces éléments SD-IoV.
Aussi, la gestion globale des informations concernant l’ensemble des éléments SD-IoV
ne présente pas de réel intérêt. En revanche, elle pourrait conduire à une surcharge du
réseau Blockchain. En effet, les demandes de mises à jour des informations relatives aux
éléments SD-IoV sont gérées par l’ensemble des noeuds Blockchain.
135
F IGURE 5.1 – Architecture Blockchain proposée
C’est pourquoi, comme cela est visible sur la figure 5.1, nous proposons de consi-
dérer la séparation du réseau Blockchain global en un ensemble de sous-réseaux Blo-
ckchain. Chaque sous-réseau (cf. Figure 5.1 : SN1, SN2, SN3) gérerait une zone géo-
graphique spécifique et un nombre d’éléments SD-IoV limité. Ces éléments SD-IoV cor-
respondraient à un ensemble d’équipements actuellement situés dans cette zone géo-
graphique (contrôleurs, équipements de bord de route, équipement terminaux) ainsi
qu’aux applications SDN nécessaires au fonctionnement du réseau SD-IoV. Notre ap-
proche, limitant la charge (quantité de données stockées, nombre de requêtes) de cha-
cun des sous-réseaux et noeuds Blockchain, permettrait, par conséquent, de garantir un
meilleur passage à l’échelle (cf. Section 5.5.3).
Toutefois, certains éléments SD-IoV pourraient se déplacer d’une zone géographique
à une autre, notamment les équipements terminaux. De même, des contrôleurs SD-IoV
situés dans un sous-réseau Blockchain pourraient chercher à communiquer avec des
136
contrôleurs situés dans un sous-réseau voisin. Aussi, il est nécessaire que des commu-
nications puissent s’établir entre les différents sous-réseaux Blockchain. Pour ce faire,
nous proposons d’ajouter aux sous-réseaux Blockchain (cf. Figure 5.1 : SN1, SN2, SN3)
un réseau Blockchain global (cf. Figure 5.1 : GN). Ce réseau global interconnecte des
noeuds appartenant à chacun des sous-réseaux Blockchain. Ainsi, il permet à chaque
sous-réseau de récupérer des informations concernant les sous-réseaux voisins : noeuds
Blockchain présents, état de ces noeuds (actif ou non), etc. Ces informations pourront
être utilisées pour gérer l’authentification (cf. Section 5.4.3.2) et le contrôle d’accès (cf.
Section 5.4.3.3) d’équipements terminaux se déplaçant entre différents sous-réseaux
ainsi que les communications inter-contrôleurs.
Aussi, considérant la définition de sous-réseaux Blockchain, la nécessité de parta-
ger globalement des informations, et la nécessité de gérer la mobilité des équipements
terminaux, notre approche s’appuie sur trois types de noeuds Blockchain :
— les noeuds locaux : ces noeuds sont impliqués dans un sous-réseau unique (cf.
Figure 5.1 : L1, L2). Leur rôle consiste à authentifier et à contrôler l’accès des élé-
ments SD-IoV actuellement situés dans la zone géographique où ils opèrent. Par
exemple, le noeud L1 (cf. Figure 5.1) serait en mesure d’authentifier les équipe-
ments terminaux actuellement situés dans SN1 ;
— les noeuds inter-sous-réseaux : ces noeuds sont impliqués dans deux (ou plus)
sous-réseaux Blockchain (cf. Figure 5.1 : I1, I2, I3, I4). Disposant des fonctionna-
lités des noeuds locaux, ils permettent l’authentification/contrôle d’accès à l’inté-
rieur d’une zone géographique donnée. De plus, étant impliqués dans différents
sous-réseaux, ils assurent la gestion des transitions inter-zones géographiques
(sud) ou l’établissement de communications entre contrôleurs SD-IoV situés dans
des sous-réseaux différents (est/ouest). Par exemple, le noeud I2 (cf. Figure 5.1),
étant impliqué dans les sous-réseaux SN1 et SN2, serait en mesure d’authentifier
et de contrôler l’accès des équipements terminaux transitant de SN1 vers SN2 ;
— les noeuds globaux : ces noeuds sont impliqués dans le réseau Blockchain global
(cf. Figure 5.1 : G1, G2, G3). Disposant des fonctionnalités des noeuds locaux,
ils permettent l’authentification/contrôle d’accès à l’intérieur d’une zone géogra-
phique donnée. De plus, étant impliqués dans le réseau Global, ils permettent à
chaque sous-réseau Blockchain de récupérer des informations concernant les sous-
137
réseaux alentours : noeuds existants, disponibilité, etc. Par exemple, le noeud G1

(cf. Figure 5.1), étant impliqué dans GN, serait en mesure de transmettre aux
noeuds de SN1 des informations concernant les noeuds de SN2 et SN3.
Ainsi, dans l’exemple présenté dans la figure 5.1, trois sous-réseaux locaux (SN1,
SN2, SN3), un réseau global (GN), trois noeuds globaux (G1, G2, G3), quatre noeuds
inter-sous-réseaux (I1, I2, I2, I4) et deux noeuds locaux (L1, L2) sont considérés.
Il est à noter que les dimensions maximales d’une zone géographique, et donc
d’un sous-réseau Blockchain, pourraient correspondre aux frontières des pays. En effet,
comme cela est fait dans les projets pilotes pour le déploiement des réseaux véhicu-
laires [KP15], considérer chaque pays comme une entité indépendante permet d’éviter
les problèmes législatifs liés aux réglementations en vigueur dans chacun de ces pays.
Néanmoins, pour des pays à la superficie et la densité importantes (États-Unis, Chine),
il pourrait être intéressant de considérer des sous-réseaux de plus faible dimension :
région, ville. Ceci permettrait de garantir des performances élevées dans tout type de
situation. Dans la section 5.6.1, nous évaluerons le nombre optimal de sous-réseaux
Blockchain en considérant le déploiement de réseaux SD-IoV aux États-Unis.
Dans la section suivante (cf. Section 5.4.3) nous présentons les mécanismes permet-
tant de garantir l’authentification (cf. Section 5.4.3.2) et le contrôle d’accès (cf. Section
5.4.3.3) des éléments SD-IoV dans l’environnement proposé.
5.4.3 Sécurisation des communications

Considérant un modèle d’enregistrement de certificats similaire au modèle actuel-
lement utilisé dans l’environnement véhiculaire (cf. Section 5.4.3.1), nous proposons
dans cette section des mécanismes permettant le chiffrement et l’authentification (cf.
Section 5.4.3.2), et le contrôle d’accès (cf. Section 5.4.3.3), des éléments SD-IoV.
5.4.3.1 Modèle d’enregistrement des éléments SD-IoV
Notre objectif est de concevoir une solution de sécurisation des interfaces SD-IoV,
interopérable avec l’architecture SD-IoV actuelle (cf. Section 5.4.1). Aussi, nous propo-
sons de baser le fonctionnement du protocole TLS sur la Blockchain (cf. Figure 5.2).
En effet, l’utilisation de ce protocole est possible au niveau de l’ensemble des interfaces
SD-IoV (sud, est/ouest, nord). De plus, en utilisant la Blockchain pour la gestion des cer-
tificats, les problèmes liés aux approches PKI centralisées pourraient être résolus : point
138
d’attaque unique, complexité du processus de révocation, manque de transparence (cf.

Section 3.2.1). Enfin, les auteurs de [KKM19] ont démontré que les performances de
TLS, notamment en terme de latence, pourraient être améliorées en l’interconnectant à
une PKI décentralisée (Blockchain).
Ainsi, nous proposons de baser l’enregistrement, le stockage et la mise à jour des
certificats X.509 sur la Blockchain. Pour ce faire, une PKI décentralisée est implémentée
à l’intérieur de smart contracts [YSW+ 18], déployés au niveau de chacun des noeuds
Blockchain. Cette gestion des certificats X.509 dans un environnement Blockchain est
possible grâce à une utilisation efficace des extensions des certificats X.509. En effet, ces
extensions peuvent être utilisées pour définir l’adresse du smart contract ayant émis le
certificat X.509, l’adresse du noeud Blockchain correspondant ainsi que l’identifiant du
réseau Blockchain. Ceci permet, par conséquent, une vérification simple des informa-
tions contenues dans le certificat lors de l’instantiation d’une communication sécurisée
entre deux clients TLS. Dans la section 5.4.3.2, l’utilisation de ces informations pour
l’authentification des éléments SD-IoV sera présentée.
Considérant que la Blockchain fait office de PKI et d’entité de gestion des privilèges,
l’enregistrement d’un nouvel élément SD-IoV est possible en envoyant une requête de
signature de certificat (Certificate, Signing Requests 1 ) à la Blockchain. Ainsi, cette ap-
proche offre une solution transparente durant les phases d’enregistrement (le protocole
d’enregistrement étant le même que celui actuellement utilisé pour les certificats X.509)
et d’authentification (l’utilisation d’une PKI décentralisée n’impacte pas le fonctionne-
ment du protocole).
Pour l’enregistrement des différents éléments SD-IoV, le modèle suivant est adopté :
— pour les véhicules : comme cela est proposé dans les projets pilotes pour le
déploiement des réseaux véhiculaires [KP15], nous considérons que l’enregistre-
ment des véhicules est réalisé par les constructeurs automobiles. Ainsi, lorsqu’un
constructeur automobile met un nouveau véhicule sur le marché, il l’enregistre
dans le sous-réseau Blockchain dans lequel ce véhicule devrait être mis en activité.
Pour ce faire, il génère le couple de clé publique/clé privée et soumet la requête de
signature de certificat au sous-réseau Blockchain souhaité. Un certificat est alors
fourni au véhicule ;
1. RFC 8446, Rescorla, Eric and Dierks, Tim, The transport layer security (TLS) protocol version 1.3
https://www.hjp.at/doc/rfc/rfc8446.html
139
— pour les autres éléments SD-IoV : l’enregistrement des autres éléments (équi-
pements réseau, téléphones mobiles, contrôleurs SDN, applications SD-IoV) est
réalisé par les opérateurs mobiles. Ainsi, pour les équipements réseau, téléphones
mobiles, contrôleurs SDN, l’opérateur les enregistre dans le sous-réseau géogra-
phique dans lequel ils devraient être mis en activité. Pour ce qui est des applica-
tions SDN, l’opérateur est en charge de les enregistrer dans l’ensemble des sous-
réseaux où ces applications pourraient s’avérer utiles.
Il est à noter que les certificats des équipements terminaux, contrôleurs SDN et équi-
pements réseau sont uniquement stocké dans un seul sous réseau, correspondant à la
zone géographique dans laquelle ils sont mis en activité.
S’appuyant sur ce modèle d’enregistrement, dans les sections suivantes, nous propo-
sons des mécanismes d’authentification (cf. Section 5.4.3.2) et de contrôle d’accès (cf.
Section 5.4.3.3) pour les réseaux SD-IoV.
5.4.3.2 Authentification et révocation
Comme nous l’avons évoqué dans la section précédente, la sécurisation des commu-
nications (authentification, chiffrement, contrôle d’accès) entre éléments SD-IoV repose
sur l’utilisation du protocole TLS (v1.3) 2 et de certificats X.509 (cf. Section 5.4.3.1).
Avec le protocole TLS, l’authentification mutuelle, et la négociation du mécanisme
de chiffrement à mettre en place, sont réalisés lors de la phase de "poignée de main"
(handshake protocol, cf. Figure 5.2). Aussi, c’est durant cette phase que, dans notre ap-
proche, la Blockchain est utilisée pour authentifier les éléments SD-IoV (cf. Figure 5.2 :
étapes 2 et 4). Pour ce faire, comme nous l’avons indiqué dans la section précédente
(cf. Section 5.4.3.1), les extensions des certificats X.509 sont utilisées. Grâce à ces ex-
tensions, il est possible de définir :
— network-id : l’identifiant du/des sous-réseau(x) Blockchain dans lequel/lesquels

ce certificat est stocké ;
— smart-ad : l’adresse du smart contract qui a généré ce certificat (ou les adresses si
le certificat est stocké dans plusieurs sous-réseaux Blockchain) ;
2. RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3, https://tools.ietf.org/
html/rfc8446
140
— node-ad : l’adresse du noeud Blockchain qui a géré la transaction (ou les adresses
si le certificat est stocké dans plusieurs sous-réseaux Blockchain).
F IGURE 5.2 – TLS : Protocole handshake basé sur la Blockchain
Ainsi, en utilisant ces différentes extensions, et notamment network-id et smart-ad,

les clients/serveurs TLS sont en mesure de vérifier l’authenticité et la validité des certi-
ficats. Pour ce faire, durant le handshake, ils envoient au smart contract indiqué (smart-
ad), déployé dans le sous-réseau indiqué (network-id), une requête contenant le cer-
tificat X.509 à vérifier (cf. Figure 5.2 : étapes 2 et 4). La phase de handshake permet
également le calcul d’une clé symétrique de communication (Key Agreement Protocol,
Figure 5.2 : étapes 1 et 3). Par conséquent, l’utilisation du protocole TLS au niveau des
interfaces SD-IoV permet l’authentification mutuelle et le chiffrement des communica-
tions.
Néanmoins, un élément ne pourra être authentifié qu’à condition que son certificat
soit enregistré dans le/les registres Blockchain géré(s) par le noeud Blockchain auquel
il s’adresse. Comme nous l’avons expliqué dans la section 5.4.3.1, les noeuds locaux
ne seront en mesure d’authentifier que les éléments SD-IoV enregistrés dans le sous-
réseau dans lequel ils opèrent (cf. Figure 5.1 : L1 : SN1). Les noeuds inter-sous-réseaux
pourront, eux, authentifier les éléments SD-IoV enregistrés dans un des sous-réseaux
dans lesquels ils opèrent (cf. Figure 5.1 : I2 : SN1, SN2). Aussi, ce système, en l’état,
permet l’authentification à l’intérieur d’un sous-réseau (applications SDN, contrôleurs
SDN, équipements réseaux, équipements terminaux) ainsi qu’entre deux sous-réseaux
voisins. Il garantit donc l’authentification des éléments fixes (contrôleurs, applications,
équipements réseau) et des contrôleurs voisins. Par exemple, un contrôleur connecté à
141
I1 pourra communiquer avec un contrôleur connecté à I2 (cf. Figure 5.1).

En revanche, les équipements terminaux mobiles (véhicules, téléphones, etc.)
peuvent, eux, se déplacer d’un sous-réseau à un autre. Aussi, il est essentiel de pou-
voir garantir l’authentification de ces éléments SD-IoV, quels que soient leurs déplace-
ments et quel que soit le sous-réseau Blockchain dans lequel ils se situent. Par exemple,
dans la figure 5.1, il est essentiel de pouvoir authentifier au niveau de l’ensemble des
noeuds Blockchain de SN2 (I2, I3, G2) un équipement terminal arrivant de SN1. On
parle d’authentification inter-sous-réseaux.
Dans notre approche, cette authentification inter-sous-réseaux repose sur l’utilisa-
tion des noeuds Blockchain inter-sous-réseaux (cf. Figure 5.1). Les équipements termi-
naux, lorsqu’ils se connectent au réseau Blockchain pour vérifier l’authenticité d’un cer-
tificat, établissent une communication avec le noeud Blockchain le plus proche. Aussi,
lorsqu’un équipement terminal se rapprochera de la frontière entre deux sous-réseaux
Blockchain, il se connectera nécessairement à un noeud inter-sous-réseaux. C’est pour-
quoi, durant le protocole handshake, lorsqu’un noeud inter-sous-réseau Blockchain re-
çoit une demande de vérification du certificat d’un équipement terminal, il adopte la
démarche suivante (cf. Figure 5.2 : étape 2) :
1. le noeud Blockchain vérifie l’authenticité et la validité du certificat de l’équipement
terminal (dans le sous-réseau dont le nom est indiqué dans le certificat X.509 de
l’équipement terminal) ;
2. le noeud Blockchain retourne cette information au client TLS ;
3. le noeud Blockchain vérifie si ce certificat est également enregistré dans les autres
sous-réseaux dans lesquels il opère (en consultant la liste des sous-réseaux dans
lequel est enregistré ce certificat : network-id) ;
4. si ce certificat est absent dans un (ou plusieurs) de ces sous-réseaux, le noeud
Blockchain demande son ajout. Les extensions du certificat X.509 sont alors mises
à jour : network-id, smart-ad, node-ad.
Ainsi, ces noeuds Bockchain inter-sous-réseaux permettent de gérer les transi-
tions entre sous-réseaux Blockchain. Pour ce faire, ils assurent l’enregistrement (cross-
signature) des certificats X.509 des équipements terminaux dans l’ensemble des sous-
réseaux où ils pourraient être utiles. Ainsi, les certificats des différents équipements
SD-IoV sont stockés dans un nombre limité de sous-réseaux (zone où ils opèrent : équi-
142
pements réseau, contrôleurs, applications, zone de mobilité : équipements terminaux)

et leur authentification est garantie à chaque instant.
Cette architecture en sous-réseaux nécessite également une gestion particulière de
la révocation des certificats. En effet, pour certains éléments SD-IoV, notamment les
équipements terminaux et les applications, ces certificats peuvent être enregistrés dans
différents sous-réseaux. Par conséquent, la révocation doit être appliquée à l’ensemble
de ces sous-réseaux. Pour ce faire, le processus de révocation, que nous proposons, s’ap-
puie sur une des extensions du certificat : la liste des sous-réseaux où ce certificat est
stocké (network-id). En effet, ces informations sont mises à jour à chaque fois qu’un
certificat est enregistré dans un sous-réseau Blockchain. Ainsi, la liste regroupant l’en-
semble des sous-réseaux, noeuds Blockchain et smart contracts contenant ce certificat
est accessible.
Aussi, lorsqu’un noeud Blockchain souhaite révoquer un certificat, la procédure sui-
vante est adoptée :
1. le noeud Blockchain transmet cette information à l’ensemble des noeuds Block-
chain du sous-réseau dans lequel est actuellement situé l’élément SD-IoV. Le cer-
tificat de l’élément SD-IoV est donc révoqué pour ce sous-réseau ;
2. le noeud Blockchain récupère la liste des sous-réseaux Blockchain dans lesquels
est enregistré cet équipement terminal (network-id) ;
3. si le noeud Blockchain est un noeud inter-sous-réseaux, il contacte directement les
sous-réseaux concernés auxquels il est connecté. Sinon, il utilise les extensions du
certificat X.509 pour déterminer la liste des noeuds à contacter (smart-ad, node-
ad). Il est à noter que lorsque node-ad n’est pas disponible, le registre Blockchain
Global associant sous réseau et noeuds peut être utilisé (cf. Section 5.4.2) ;
4. les noeuds Blockchain contactés procèdent à la révocation du certificat. Le certifi-
cat de l’élément SD-IoV est révoqué de l’ensemble des sous-réseaux.
Ainsi, les mécanismes proposés garantissent l’authentification et la révocation des
éléments SD-IoV. De plus, le protocole TLS assure le chiffrement des communications.
5.4.3.3 Contrôle d’accès
Comme nous l’avons indiqué dans la section 5.2.1, le contrôle d’accès est également
important pour assurer la sécurisation des interfaces SD-IoV.
143
L’accès des équipements réseau et équipements terminaux est naturellement limité.

En effet, la connexion entre un équipement réseau (ou équipement terminal) et un
contrôleur SDN est réalisée par le contrôleur. Par conséquent ces éléments SD-IoV ne
sont en capacité de communiquer qu’avec le contrôleur SDN auquel ils sont connectés.
Aussi, toute communication provenant d’un élément (terminal, réseau) authentifié peut
être considérée comme autorisée. De même, les communications inter-contrôleurs sont
naturellement contrôlées. En effet, un contrôleur ne sera en capacité de communiquer
qu’avec les contrôleurs à l’intérieur du sous-réseau où il est déployé (s’il est connecté à
un noeud Blockchain local) ou avec le contrôleur faisant la jonction avec le sous-réseau
voisin (s’il est connecté à un noeud Blockchain inter-sous-réseaux).
En revanche, l’authentification est insuffisante pour assurer le contrôle d’accès des
contrôleurs (interface sud) et applications (interface nord). En effet, un contrôleur ou
une application pourrait établir une communication avec l’ensemble des équipements
présents dans un sous-réseau Blockchain. Or, un sous-réseau Blockchain ne correspond
pas nécessairement à un seul contrôleur et les droits des applications ne sont pas néces-
sairement les mêmes pour l’ensemble de ces contrôleurs. Par conséquent, la limitation
de leurs droits est essentielle afin de réduire la capacité d’attaque d’un élément mal-
veillant ou compromis.
C’est pourquoi nous proposons de définir des aires géographiques à l’intérieur des
différents sous-réseaux Blockchain. Ainsi, chaque sous-réseau Blockchain (pays, région,
ville) serait divisé en sous-ensembles de taille réduite : région/ville/quartier, rue, etc.
Par exemple, dans la figure 5.1, le sous-réseau SN1 pourrait être divisé en deux zones
géographiques différentes : A1 et A2.
Cette approche permettrait de limiter les droits accordés aux applications et contrô-
leurs SD-IoV. Pour ce faire, nous proposons qu’au moment de l’enregistrement des élé-
ments SD-IoV, l’opérateur réseau leur attache également une zone géographique, cor-
respondant à la zone dans laquelle ils seront mis en activité. Ainsi, chaque équipement
réseau pourrait être affecté à une zone géographique particulière (cf. Figure 5.1 : A1,
A2, A3, A4, A5). De même, chaque contrôleur et chaque application SD-IoV pourrait
être attaché à une ou plusieurs zones géographiques (cf. Figure 5.1 : C0 : A1, App A :
A1, A5).
Cette information pourrait être utilisée lors du processus d’authentification par le
client TLS pour vérifier que le serveur TLS est bien un serveur autorisé (cf. Figure 5.2 :
144
Etape 4). Ainsi, en comparant les certificats des clients et serveurs, le sous-réseau Blo-
ckchain pourrait vérifier qu’un contrôleur SD-IoV est bien autorisé à intervenir dans
la zone géographique dans laquelle se situe l’équipement réseau. De même, ce sys-
tème permettrait de vérifier qu’une application SD-IoV est bien autorisée à intervenir
dans la zone géographique d’un contrôleur SD-IoV donné. Cette approche permet, par
conséquent, de garantir le contrôle d’accès lors des échanges entre équipements réseau,
contrôleurs SD-IoV et applications SD-IoV.
Néanmoins, pour l’établissement des communications entre contrôleurs SD-IoV et
équipements terminaux, le processus est plus complexe. En effet, les équipements ter-
minaux étant mobiles, il est impossible de leur attacher une zone géographique fixe.
C’est pourquoi, nous proposons une gestion dynamique de la zone géographique atta-
chée au certificat des équipements terminaux.
Pour ce faire, à chaque établissement d’une communication sécurisée entre un équi-
pement terminal et un équipement de bord de route (protocole TLS handshake), le
sous-réseau Blockchain récupère le nom de la zone géographique à laquelle est attaché
cet équipement de bord de route (contenu dans son certificat). Ensuite, le sous réseau
vérifie si ce nom correspond ou non à celui de la dernière zone géographique enregis-
trée pour l’équipement terminal (cf. Figure 5.2 : Etape 2). Si ce n’est pas le cas, la zone
géographique dans laquelle se situe cet équipement est mise à jour dans son certifi-
cat. Ceci permet donc de connaître à tout moment la zone géographique dans laquelle
est situé cet équipement. Par conséquent, lors de l’établissement d’une communication
entre équipement terminal et contrôleur SD-IoV, cet équipement sera en mesure de
déterminer si ce contrôleur opère bien dans la zone géographique dans laquelle il se
trouve actuellement. L’ensemble de la procédure de gestion du contrôle d’accès entre
équipement terminal et contrôleur SD-IoV peut être résumée ainsi :
— l’opérateur réseau attache les équipements réseaux et contrôleurs SD-IoV à des

zones géographiques particulières (cf. Figure 5.1 : A1, A2, A3, A4, A5) ;
— quand un équipement terminal établit une communication sécurisée avec un équi-

pement de bord de route (handshake), le sous-réseau Blockchain vérifie que la
zone géographique de cet équipement de bord de route correspond bien à la der-
nière zone géographique enregistrée pour l’équipement terminal ;
— si ce n’est pas le cas, la zone géographique de l’équipement terminal est mise à
145
jour dans le certificat de l’équipement terminal (cf. Figure 5.2 : Etape 2) ;
— quand un contrôleur SD-IoV tente de se connecter à un équipement terminal, le

sous-réseau Blockchain vérifie que ce contrôleur SD-IoV est bien autorisé à opérer
dans cette zone géographique (cf. Figure 5.2 : Etape 4) ;
— si ce n’est pas le cas, la connexion est refusée (cf. Figure 5.2 : Etape 5).
L’approche présentée dans cette section, permet donc de garantir le contrôle d’accès
au niveau des différentes interfaces SD-IoV. Dans la section suivante les performances
de ce mécanisme (cf. Section 5.5.5) et des autres évolutions proposées dans ce chapitre
(cf. Sections 5.5.3, 5.5.4) seront évaluées.
5.4.4 Résumé
Dans cette section, nous avons introduit une nouvelle solution utilisant la Blockchain
pour sécuriser les interfaces SD-IoV (cf. Section 5.4.1). Cette solution se base sur trois
éléments principaux. Tout d’abord une architecture Blockchain innovante devant garan-
tir le passage à l’échelle (cf. Section 5.4.2). Ensuite, des mécanismes d’authentification
et de révocation, compatibles avec le protocole TLS, et adaptés à l’architecture propo-
sée (cf. Section 5.4.3.2). Enfin, un mécanisme de contrôle d’accès limitant la capacité
d’attaque des éléments SD-IoV malveillants/compromis (cf. Section 5.4.3.3).
5.5 Évaluation des performances

Dans cette section, la solution proposée (cf. Section 5.4) est comparée aux approches
introduites dans la littérature (cf. Section 5.3.4).
5.5.1 Objectifs
Les solutions proposées dans la littérature peuvent être classées en deux catégories
(cf. Section 5.3.4). D’un côté, celles qui proposent de sécuriser les interfaces SD-IoV en y
ajoutant une couche de sécurité basée sur la Blockchain. De l’autre, celles qui proposent
de faire évoluer le fonctionnement même de ces interfaces, en basant les échanges entre
les différents éléments SD-IoV sur la Blockchain.
Notre objectif étant de proposer une solution interopérable avec l’environnement
existant (cf. Section 5.2.1), nous avons décidé de centrer notre comparaison sur les
146
approches proposant la sécurisation des interfaces SD-IoV. Ces solutions existantes, sé-
curisant les différentes interfaces grâce à la Blockchain, s’appuient sur des modèles simi-
laires. En effet, les principales différences concernent le type de certificat choisi (X.509
ou non), les fonctions de hachage utilisées et les informations ajoutées au certificat :
nom de la Blockchain, adresse du smart contract, etc. Aussi, pour notre évaluation, nous
avons décidé de sélectionner une solution représentative de celles proposées dans la lit-
térature, basée sur le même type de certificats que celui proposé dans notre approche
(X.509), et interopérable avec les systèmes existants : [YSW+ 18].
En comparaison avec cette approche, au delà de la sécurisation de l’ensemble des
interfaces SD-IoV, la solution que nous proposons présente trois différences principales.
Tout d’abord, la proposition d’une nouvelle architecture Blockchain composée d’un en-
semble de sous-réseaux (cf. Section 5.4.2). Ensuite, la proposition d’un mécanisme ga-
rantissant l’authentification et la révocation des certificats dans cet environnement (cf.
Section 5.4.3.2). Enfin, la définition d’un mécanisme garantissant un contrôle d’accès
efficace (cf. Section 5.4.3.3). Aussi, considérant nos objectifs initiaux (cf. Section 5.2.1),
dans cette expérimentation nous avons décidé d’évaluer :
— les bénéfices en terme de passage à l’échelle de l’architecture Blockchain proposée
(cf. Section 5.5.3) ;
— l’impact, notamment en termes de débit et de latence, des mécanismes d’authen-
tification/révocation proposés (cf. Section 5.5.4) ;
— l’impact, en termes de débit et de latence, du mécanisme de contrôle d’accès pro-
posé (cf. Section 5.5.5).
5.5.2 Environnement de test

Cette expérimentation a nécessité différents outils :
— l’implémentation en langage Go d’Hyperledger Fabric (v1.4.2), un framework Blo-
ckchain modulaire, permettant la mise en place de réseaux et applications Block-
chain [ABB+ 18]. Cet outil a permis l’émulation de l’environnement Blockchain ;
— GoLevelDB une base de données de type clé-valeur implémentée en langage Go 3 .
Cette base de données a été utilisée dans notre évaluation pour le stockage des
données au niveau de chaque noeud (pair) Blockchain ;
3. LevelDB key/value database in Go, https://github.com/syndtr/goleveldb
147
— le concept de "canal" (channel) proposé par Hyperldeger Fabric. Cette fonctionna-

lité, offerte par Hyperledger Fabric, permet la définition de sous-réseaux privés à
l’intérieur d’un réseau Blockchain Global [BSV+ 18]. Ces sous-réseaux privés in-
terconnectent un nombre réduit de noeuds Blockchain, sous-ensemble du réseau
Blockchain global. Ces canaux on été utilisés dans notre évaluation pour la mise
en place de sous-réseaux Blockchain géographiques (cf. Section 5.4.2) ;
— un algorithme visant à simuler la mobilité des terminaux SD-IoV 4 . Cet algorithme
permet de connecter les terminaux à différents noeuds Blockchain au cours du
temps, en fonction de paramètres pré-définis : nombre d’équipements terminaux
mobiles, noeud Blockchain de destination, etc. Ainsi, avec cet algorithme, la per-
formance des mécanismes d’authentification et de contrôle d’accès proposés a pu
être évaluée dans des conditions de mobilité (cf. Sections 5.5.5, 5.5.4) ;
— Hyperledger Caliper [NQATN18], un outil permettant de mesurer les perfor-
mances des réseaux et applications Hyperledger, en fonction de paramètres pré-
établis : types de requêtes, nombre de requêtes par seconde, durée d’expérimen-
tation, etc. Cet outil a été ici utilisée pour réaliser la comparaison entre notre
solution et l’approche proposée dans [YSW+ 18].
Plus d’informations concernant l’implémentation de la solution proposée, les ou-
tils/scripts utilisés et les résultats obtenus sont accessibles en ligne4 .
5.5.3 Bénéfices de l’architecture Blockchain proposée

La décomposition du réseau Blockchain en un ensemble de sous-réseaux (cf. Section
5.4.2) constitue une évolution importante par rapport aux approches proposées dans la
littérature. En effet, jusqu’ici, seules des solutions basées sur un réseau Blockchain glo-
bal avaient été définies (cf. Section 5.3.4). Aussi, dans cette section, nous avons cherché
à évaluer les bénéfices de l’architecture proposée en terme de passage à l’échelle.
Pour ce faire, nous avons utilisé un réseau Blockchain composé de 8 noeuds et
avons considéré différents cas. Un premier cas où un seul réseau global est considéré
(SINGLE). Un second cas où deux sous-réseaux sont considérés (MULT-2). Un troisième
où quatre sous-réseaux sont considérés (MULT-4). Un dernier où huit sous-réseaux sont
considérés (MULT-8). Ainsi, nous avons comparé l’approche existante dans la littérature
(SINGLE) à trois implémentations de notre approche (MULT-2, MULT-4, MULT-8).
4. Github repository : github.com/lmendiboure/scalableBCforSDVN
148
Pour ces différentes approches, deux situations ont été considérées :
— READ : l’envoi de requêtes en lecture au réseau (ou sous-réseau) Blockchain. Cette

situation correspond à la vérification d’un certificat X.509 durant la phase d’au-
thentification entre deux éléments SD-IoV ;
— WRITE : l’envoi de requêtes en écriture au réseau (ou sous-réseau) Blockchain.

Cette situation correspond à l’enregistrement ou la mise à jour d’un certificat.
Pour les différentes approches (SINGLE, MULT-2, MULT-4, MULT-8), dans ces deux
situations (READ, WRITE), nous avons cherché à évaluer la capacité de passage à
l’échelle. Pour ce faire, nous avons considéré l’envoi d’un nombre variable de requêtes
par seconde au réseau (ou sous-réseau) Blockchain et avons mesuré :
— le débit : le nombre moyen de requêtes par seconde (en écriture ou lecture) que
le réseau (ou l’ensemble de sous-réseaux) Blockchain est capable de supporter ;
— la latence : la durée moyenne nécessaire au réseau (ou sous-réseau) Blockchain

pour gérer une requête (en écriture ou lecture) ;
— le taux d’utilisation des ressources CPU : le pourcentage de ressources CPU utilisé

par chaque noeud Blockchain.
Il est à noter que le nombre de requêtes par seconde correspond au nombre de

requêtes par seconde envoyées à chaque réseau (ou sous-réseau) Blockchain. Par consé-
quent, dans l’approche MULT-X, le nombre total de requêtes par seconde envoyées à
l’ensemble de sous-réseaux Blockchain sera X fois supérieur au nombre de requêtes par
seconde envoyées dans l’approche SINGLE.
Les résultats des expérimentations menées dans le cadre de cette évaluation sont
présentés en figure 5.3. Différentes observations sont possibles :
— pour le cas READ : en terme de latence et de débit, l’amélioration des perfor-

mances est directement liée à l’augmentation du nombre de sous-réseaux. Néan-
moins, les gains sont peu significatifs. En effet, entre les approches SINGLE et
MULT-8, les gains sont en moyenne de 10% pour un nombre de requêtes par se-
conde supérieur à 525. De plus, le débit maximal est d’environ 500 requêtes par
seconde pour l’approche SINGLE et de 590 requêtes par seconde pour l’approche
MULT-8. Concernant le taux d’utilisation des ressources en CPU, on peut consta-
ter qu’il reste faible quelque soit l’approche considérée. On peut également noter
149
F IGURE 5.3 – Évaluation des bénéfices de l’architecture proposée
que les approches MULT-2 et MULT-4 améliorent les performances en termes de

latence et de débit tout en maintenant un taux d’utilisation des ressources CPU
similaire à l’approche SINGLE ;
— pour le cas WRITE : les approches MULT-4 et MULT-8 permettent des gains très im-
portants en termes de latence et de débit, supérieurs à 100% en moyenne. Ainsi, le
débit maximal est d’environ 190 requêtes par seconde pour l’approche SINGLE et
450 requêtes par seconde pour l’approche MULT-8. De même, la latence minimale
passe de 8 milli-secondes à près de 4 milli-secondes. Néanmoins, on peut consta-
ter que pour un nombre élevé de requêtes par seconde (supérieur à 200 requêtes
150
par seconde), les performances en termes de débit et de latence sont dégradées.

Cette dégradation des performances est également associée à une augmentation
significative du taux d’utilisation du CPU (80% pour l’approche MULT-8 contre
moins de 30% pour les autres approches).
Ces observations démontrent que l’architecture Blockchain proposée (MULT-X) per-
met d’améliorer significativement les performances par rapport aux approches exis-
tantes (SINGLE). En effet, l’augmentation du nombre de sous-réseaux permet d’of-
frir un débit plus élevé et une latence plus faible, tant pour les requêtes en lecture
qu’en écriture. Ces gains s’expliquent par la parallélisation de certaines tâches per-
mise par la décomposition de l’architecture Blockchain en sous-réseaux. Ainsi, les tâches
d’endorsment, de commit et d’ordering, nécessaires à la gestion des requêtes en écriture,
ne sont plus réalisées par un seul réseau Blockchain mais par un ensemble de sous-
réseaux. De même, pour les requêtes en lecture, la tâche d’endorsement est parallélisée.
Ainsi, les performances (latence, débit) sont améliorées.
Néanmoins, on peut noter que dans le cas d’un niveau de charge extrême, l’approche
MULT-8 est confrontée à une dégradation des performances. Ceci s’explique par la quan-
tité insuffisante de ressources CPU à disposition. Ce manque de ressources conduit à la
saturation du réseau Blockchain et à une dégradation des performances tant en termes
de latence que de débit. Toutefois, on peut supposer que dans le cas d’un déploiement à
large échelle, la capacité CPU mise à disposition des noeuds Blockchain sera suffisante.
De plus, le calcul préalable du nombre de sous-réseaux nécessaire à la sécurisation des
communications pourra permettre d’estimer la quantité de ressources nécessaires pour
chaque noeud Blockchain constituant le réseau (cf. Section 5.6.1).
Ainsi, nous pouvons conclure de cette expérimentation que l’évolution architecturale
proposée pourrait garantir un passage à l’échelle bien plus important que les approches
considérées jusqu’ici (cf. Section 5.3.4). Cette architecture pourrait donc offrir une ré-
ponse à la problématique de passage à l’échelle du plan de sécurité et de respect de la
vie privée de l’architecture C-ITS (cf. Section 3.2.1).
5.5.4 Impact de l’authentification/révocation inter-sous-réseaux

Blockchain
L’architecture Blockchain proposée permet de garantir un passage à l’échelle plus im-
portant que les approches existantes (cf. Section 5.5.5). Néanmoins, la décomposition
151
en sous-réseaux Blockchain implique la mise en place d’un mécanisme d’authentifica-

tion/révocation inter-sous-réseaux pour gérer la mobilité des équipements terminaux.
Or, ces mécanismes nécessitent l’établissement d’une communication entre différents
sous-réseaux Blockchain. Ils pourraient donc entraîner une dégradation des perfor-
mances (latence, débit). C’est pourquoi, dans cette section nous avons cherché à évaluer
le coût associé à :
— l’authentification d’un équipement terminal se déplaçant d’un sous-réseau Block-

chain vers un autre ;
— la révocation d’un équipement terminal dont le certificat a été enregistré dans

différents sous-réseaux Blockchain.
Pour l’authentification, nous avons comparé trois cas. Un premier cas (SINGLE) où
un seul réseau Blockchain global est utilisé pour l’authentification des éléments SD-IoV.
Ce cas SINGLE correspond aux approches proposées jusqu’ici dans la littérature. Un
second cas (CA-5), correspondant à l’approche proposée (authentification inter-sous-
réseaux), dans lequel 5% des équipements terminaux s’authentifiant sont connectés à
un noeud inter-sous-réseau (authentification inter-sous-réseaux nécessaire). Un dernier
cas (CA-20), correspondant également à l’approche proposée, dans lequel 20% des équi-
pements terminaux s’authentifiant sont connectés à un noeud inter-sous-réseau.
Il est à noter que pour l’approche proposée (CA-5, CA-20), même en considérant
un sous-réseau de faible superficie (ville), il parait peu probable que 20% des équi-
pements terminaux se déplaçant dans cette ville soient actuellement connectés à un
noeud Blockchain inter-sous-réseau. De même, il parait peu probable que l’ensemble
des équipements terminaux connectés à des noeuds Blockchain inter-sous-réseaux y
soient connectés pour la première fois. En effet, une part non négligeable des déplace-
ments correspondent à des trajets domicile-travail. Par conséquent, ces deux cas (CA-5,
CA-20) pourraient correspondre à un cas de mobilité élevée (CA-5) et à un cas de mo-
bilité anormalement élevée (CA-20).
Pour ces différents cas (SINGLE, CA-5, CA-20), nous avons cherché à évaluer les per-
formances du processus d’authentification. Pour ce faire, nous avons considéré l’envoi
d’un nombre variable de requêtes (demandes d’authentification) par seconde et avons
mesuré :
— le débit (cf. Section 5.5.5) ;
152
— la latence (cf. Section 5.5.5) ;

— le nombre de lectures et d’écritures dans le registre Blockchain.
Concernant la révocation, nous avons comparé quatre cas distincts. Un premier cas
(SINGLE) où la révocation n’est nécessaire que dans un seul réseau. Ce cas SINGLE
correspond aux approches proposées jusqu’ici dans la littérature. Un second cas (CR-
2) où la révocation est nécessaire dans deux sous-réseaux. Un troisième cas (CR-4)
où la révocation est nécessaire dans quatre sous-réseaux. Un dernier cas (CR-8) où la
révocation est nécessaire dans huit sous-réseaux.
Pour chacun de ces cas (SINGLE, CR-2, CR-4, CR-8), nous avons cherché à évaluer
les performances du processus de révocation. Pour ce faire, nous avons considéré l’en-
voi d’un nombre variable de requêtes (demandes de révocation) par seconde et avons
mesuré la latence associée au processus de révocation. Considérant que le nombre de ré-
vocations serait bien inférieur au nombre de demandes d’authentification, nous n’avons
pas cherché à mesurer le débit dans cette situation.
F IGURE 5.4 – Évaluation de l’impact des mécanismes d’authentification/révocation pro-

posés
153
présentés en figure 5.4. Différentes observations sont possibles :
— pour l’authentification : on peut observer que, quel que soit le cas (SINGLE, CA-
5, CA-20) et le nombre de requêtes par seconde considérés, la latence reste la
même. Concernant le débit, on peut constater que la différence est faible entre
les cas SINGLE et CA-5. En effet, quel que soit le nombre de requêtes par seconde
considéré, la différence ne dépasse jamais 5%. En revanche, le cas CA-20 entraîne
une importante dégradation en terme de débit. En effet, pour un nombre élevé de
requêtes par seconde (>625), le débit est quasiment 20% inférieur dans le cas CA-
20 au cas SINGLE. Enfin, on peut noter que les cas CA-5 et CA-20 entraînent une
augmentation significative du nombre de requêtes en écriture/lecture envoyées
au réseau Blockchain, de l’ordre de 10% (CA-5) et 40% (CA-20) en moyenne ;
— concernant la révocation : on peut constater que le cas SINGLE permet de garantir

une latence réduite par rapport aux cas CR-2, CR-4 et CR-8, de l’ordre de 6% en
moyenne. Ainsi, dans le cas SINGLE, l’information concernant la révocation d’un
certificat est plus rapidement transmise à l’ensemble du sous-réseau. Toutefois, on
peut également remarquer que, quel que soit le nombre de sous-réseaux considéré
(2, 4, 8), les performances (latence) offertes par les cas CR-X sont similaires.
Ces observations démontrent que la solution proposée permet de garantir des per-
formances élevées, tant pour l’authentification que pour la révocation :
— pour l’authentification, la mise en place de sous-réseaux n’entraîne pas une aug-

mentation de la latence et permet donc de garantir une latence acceptable pour
l’authentification. Ceci s’explique par le mécanisme d’authentification inter-sous-
réseaux mis en place (cf. Section 5.4.3.2). Lors du processus d’authentification
inter-sous-réseaux, le noeud Blockchain vérifie l’authenticité du certificat et four-
nit une réponse au client/serveur TLS avant d’ajouter le certificat au sous-réseau
voisin. Par conséquent, cette opération n’implique pas de latence pour le client.
En revanche, ce mécanisme nécessite un nombre de lectures/écritures plus impor-
tant dans le sous-réseau Blockchain permettant l’ajout du certificat au sous-réseau
voisin. Ce fonctionnement explique donc également la réduction du nombre de re-
quêtes par seconde que le sous-réseau est en capacité de gérer. Néanmoins, comme
nous l’avons démontré dans la section 5.5.5, l’architecture Blockchain considérée
permet d’augmenter fortement la capacité de passage à l’échelle. Par conséquent,
154
la réduction de débit induite par le processus d’authentification inter-sous-réseaux

est faible devant les gains permis par l’approche. De plus, on peut considérer que
les cas de mobilité ici correspondent à des cas de forte mobilité et de mobilité
anormalement élevée. Enfin, on peut remarquer que le pré-enregistrement des
équipements terminaux dans un ensemble de sous-réseaux Blockchain offrirait
une réponse à ce problème. En effet, dans ce cas de figure, l’authentification inter-
sous-réseaux ne serait plus nécessaire. Ce point sera discuté dans la section 5.6.1 ;
— pour la révocation inter-sous-réseaux, l’approche proposée induit une faible aug-
mentation de la latence (de l’ordre de 6% en moyenne). On peut, également,
constater que cette augmentation est constante, quel que soit le nombre de
sous-réseaux Blockchain considéré. Ceci est dû à la parallélisation de la révoca-
tion : l’ensemble des sous-réseaux effectuent cette action en parallèle (cf. Section
5.4.3.2). Cette constance témoigne, également, de la capacité de notre architec-
ture à passer à l’échelle. Quel que soit le nombre de sous-réseaux Blockchain, la
durée nécessaire à la révocation restera donc constante. De plus, on peut noter
que la latence induite par notre approche est en grande partie induite par le délai
nécessaire à un noeud Blockchain pour établir une connexion avec un sous-réseau
Blockchain. Aussi, considérant que de nombreux travaux oeuvrent encore à l’amé-
lioration de cette technologie Blockchain, on peut supposer qu’à l’avenir ce délai
de connexion sera réduit.
Ainsi, nous pouvons conclure de cette expérimentation que l’évolution architecturale
proposée, garantissant un passage à l’échelle important (cf. Section 5.5.5), a un impact
faible sur l’authentification et la révocation des certificats. Par conséquent, cette ap-
proche semble être en mesure de répondre aux problèmes identifiés (cf. Section 5.4.1).
5.5.5 Impact du contrôle d’accès

Afin de garantir un niveau de sécurité élevé, et de limiter la capacité d’actions
d’éléments malveillants/compromis, nous avons introduit un nouveau mécanisme de
contrôle pour les interfaces SD-IoV (cf. Section 5.4.3.3). Aussi, dans cette section, nous
avons cherché à évaluer le surcoût associé à la mise en place de ce contrôle d’accès.
Pour ce faire, nous avons considéré deux cas. Le premier correspond, pour notre
approche, à une authentification sans contrôle d’accès (BASIC). Le second, également
pour notre approche, correspond à une authentification avec contrôle d’accès (AC).
155
En effet, comme cela est indiqué dans la section 5.4.3.3, la mise en place du contrôle
d’accès est proposée pendant le processus d’authentification entre éléments SD-IoV.
Pour chacun de ces deux cas (BASIC, AC), nous avons considéré l’envoi d’un nombre
variable de requêtes (demandes de vérification d’un certificat) par seconde et avons
mesuré la latence et la bande passante associées.
F IGURE 5.5 – Évaluation de l’impact du mécanisme de contrôle d’accès proposé
présentés en figure 5.5. On peut constater que l’ajout du contrôle d’accès au processus
d’authentification a un faible impact sur les performances. En effet, quel que soit le
nombre de requêtes par seconde considéré, la différence observée entre l’approche AC
et l’approche BASIC n’excède jamais 5% tant pour le débit que pour la latence. Cette
différence tend d’ailleurs à se réduire pour un nombre de requêtes par seconde élevé
(environ 3-4%).
Ces observations semblent donc démontrer que l’ajout du contrôle d’accès, essentiel
pour la sécurisation des communications, n’est pas incompatible avec le maintien de
performances acceptables. En effet, celui ci repose sur la définition de zones géogra-
phiques dans lesquelles les éléments SD-IoV sont autorisés à communiquer. Par consé-
quent, l’ajout du contrôle d’accès au processus d’authentification nécessite simplement
la récupération et la comparaison de deux valeurs (zones géographiques des éléments
SD-IoV). Ceci explique le faible impact sur les performances, tant en termes de latence
que de débit.
Toutefois, pour la gestion de la mobilité des équipements terminaux, la mise en
place du contrôle d’accès entraîne l’envoi d’un grand nombre de requêtes en écriture
au réseau Blockchain. En effet, à chaque fois qu’un équipement terminal se déplace
156
d’une zone géographique vers une autre, cette information doit être stockée dans le
certificat de cet équipement terminal (cf. Section 5.4.3.3). C’est pourquoi, l’impact de
ces requêtes en écriture sur le déploiement des sous-réseaux Blockchain est discuté dans
la section 5.6.1. De plus, une solution permettant de limiter le nombre de requêtes en
écriture pour la mise à jour des certificats sera introduite dans les perspectives de ces
travaux de thèse (cf. Section 6.2).
Ainsi, nous pouvons conclure de cette expérimentation que l’introduction du mé-
canisme de contrôle d’accès, renforçant la sécurité des interfaces SD-IoV, a un impact
faible sur les performances, tant en termes de latence que de débit. Son implémentation
parait, par conséquent, réaliste. De plus, des solutions existent pour limiter le nombre
de requêtes en écriture nécessaires à la gestion de ce processus (cf. Sections 5.6.1, 6.2).
5.5.6 Résumé
Dans cette section, nous avons comparé les performances de notre solution à celles
des approches existantes (cf. Section 5.5.1). Ceci nous a permis de confirmer que la
décomposition en sous-réseaux garantit un passage à l’échelle important (cf. Section
5.5.3). De plus, cette évaluation nous a permis de démontrer le faible impact en termes
de latence et de débit des mécanismes d’authentification/révocation (cf. Section 5.5.4)
et de contrôle d’accès (cf. Section 5.5.5). Par conséquent, la solution introduite ici (cf.
Section 5.4) offre des performances similaires aux approches existantes, tout en garan-
tissant un meilleur niveau de sécurité et de passage à l’échelle.
5.6 Cas d’étude : Estimation du nombre optimal de

sous-réseaux
5.6.1 Estimation du nombre optimal de sous-réseaux
Dans cette section, nous nous proposons d’étudier comment l’architecture Block-
chain proposée (cf. Section 5.4.2) pourrait être déployée dans un environnement réel
afin d’en démontrer la faisabilité. Plus précisément, nous proposons d’estimer le nombre
de sous-réseaux qui devraient être déployés dans un environnement réel pour garantir
la sécurisation des réseaux SD-IoV et un niveau de performances élevé.
Comme nous l’avons indiqué dans la section 5.4.2, afin d’éviter des problèmes po-
tentiels de législation, la taille maximale à considérer pour un sous-réseau Blockchain
157
semble être celle d’un pays. C’est d’ailleurs l’approche adoptée par les projets pilotes
dans les réseaux véhiculaires (cf. Section 5.4.2). En revanche, pour des pays de grandes
superficie et densément peuplés (États-Unis, Chine, etc.), il pourrait être intéressant de
considérer des sous-réseaux Blockchain de plus petites dimensions. En effet, les perfor-
mances d’un sous-réseau Blockchain pourraient être influencées par :
— la quantité de données devant être stockée dans ce sous-réseau Blockchain. Dans

un livre blanc, concernant la technologie Blockchain Ethereum [B+ 14], une taille
de 100 To (tera-octet) a été définie comme une taille maximale ne devant pas être
dépassée pour garantir un niveau de performance et de décentralisation élevés ;
— le nombre maximal simultané de requêtes en écriture (enregistrements de certifi-

cats/mises à jour) que ce sous-réseau Blockchain est en capacité de supporter. Les
concepteurs d’Hyperledger Fabric, ont estimé que le nombre maximal de transac-
tions que pourrait supporter un registre Blockchain est égal à 20000 [GLGK19] ;
— le nombre maximal simultané de requêtes en lecture (vérification d’un certificat)

que ce sous-réseau Blockchain pourrait être en mesure de supporter. Les techno-
logies Blockchain visent à offrir des performances similaires aux bases de don-
nées traditionnelles. Le nombre de requêtes simultanées par seconde supporté par
chaque noeud Blockchain pourrait donc être de plusieurs dizaines de millions.
Par conséquent, le nombre de sous-réseaux devant être mis en place est directe-
ment lié au nombre d’éléments SD-IoV utilisant ce sous-réseau (quantité de données à
stocker) et au nombre de requêtes (lecture/écriture) émises par ces éléments.
Aussi, pour ce cas d’étude, nous avons décidé d’évaluer le nombre de sous-réseaux
optimal pour garantir la sécurisation des communications SD-IoV aux États-Unis. En
effet, les États-Unis sont, avec la Chine, un des pays où le plus grand nombre d’équipe-
ments terminaux (téléphones portables, véhicules) sont actuellement en circulation. Il
s’agit, par conséquent, d’un pays qui nécessiterait le déploiement du plus grand nombre
de sous-réseaux. De plus, de nombreuses informations concernant les Etats Unis (équi-
pements terminaux, stations de base, frontières) sont accessibles. Cet exemple semble
donc pertinent pour évaluer l’approche proposée dans un cas extrême.
Considérant que le nombre de contrôleurs et d’applications SD-IoV sera très infé-
rieur au nombre d’équipements de bord de route, lui-même très inférieur au nombre
d’équipements terminaux (véhicules, téléphones portables), le nombre d’éléments SD-
158
IoV à authentifier aux États-Unis peut être estimé à 540 millions. Il s’agit de la somme
du nombre de véhicules 5 (276.4M), de téléphones portables 6 (263.2M) et de stations
de base 7 (0.4M) estimé en 2017 aux États-Unis.
Partant de ce nombre d’éléments SD-IoV (540M), on peut considérer que les re-
quêtes en lecture ont un impact faible sur l’estimation du nombre de sous-réseaux Blo-
ckchain optimal pour gérer les États-Unis. En effet, comme nous l’avons noté, les tech-
nologies Blockchain visent à garantir des performances similaires aux bases de données
traditionnelles. Chaque noeud Blockchain pourrait donc être en mesure de gérer simul-
tanément une dizaine de millions de requêtes en lecture. Aussi, même en supposant
que chaque élément SD-IoV émette une requête d’authentification toute les secondes,
un sous-réseau Blockchain composé d’une cinquantaine de noeuds Blockchain pourrait
permettre de gérer l’ensemble de ces requêtes. La séparation du sous-réseau Block-
chain gérant les États-Unis en un ensemble de sous-réseaux locaux (états, villes, etc.)
ne semble pas nécessaire pour la gestion des requêtes en lecture.
De même, le stockage des certificats créés pour ces éléments SD-IoV n’impacte pas
la définition d’un nombre optimal de sous-réseaux Blockchain pour gérer les États-Unis.
Ces certificats pourraient être stockés dans les sous-réseaux Blockchain sous un format
PEM (Privacy Enhanced Mail), un format couramment utilisé et d’une taille maximale
de fichier de 8Ko 8 (Kilo-octet). En supposant que la taille de chacun des certificats
soit égale à la taille maximale (8Ko), l’espace nécessaire pour stocker les certificats
de l’ensemble des éléments SD-IoV serait de 4.32To. Cette taille est bien inférieure à
la taille maximale identifiée pour un registre Blockchain (100To). Par conséquent, la
séparation du sous-réseau Blockchain gérant les États-Unis en un ensemble de sous-
réseaux locaux (états, villes, etc.) ne semble pas nécessaire pour l’enregistrement des
certificats des éléments SD-IoV.
Il est d’ailleurs à noter que de nombreux travaux, à l’image de [MMM+ 16], visent à
permettre un stockage des données externe au registre Blockchain. Ainsi, seul le hash
des données serait stocké dans le registre Blockchain. Les données, elles, seraient enre-
gistrées dans une base de données sécurisée connectée à chaque noeud Blockchain. Ceci
5. https://www.fhwa.dot.gov/policyinformation/statistics/2017/mv1.cfm
6. https://fr.statista.com/statistiques/559597/utilisateurs-de-\
telephone-mobile-aux-etats-unis-de--a-2019/
7. https://www.ctia.org/news/the-state-of-wireless-2018
8. https://www.cisco.com/c/en/us/td/docs/wireless/asr_5000/21-3_N5-5/ePDG/
21-3-ePDG-Admin/21-3-ePDG-Admin_chapter_011100.pdf
159
permettrait d’améliorer le passage à l’échelle des réseaux Blockchain. Par conséquent,

l’approche Blockchain semble offrir une solution fiable pour le stockage des certificats
des éléments SD-IoV, même en considérant que le nombre d’éléments SD-IoV pourrait
fortement augmenter à l’avenir. On peut, également, noter que le stockage des certificats
ne représentant pas une contrainte, les certificats de l’ensemble des éléments SD-IoV
d’un pays pourraient être stockés dans les différents sous-réseaux Blockchain déployés
dans ce pays. Ceci permettrait de limiter le surcoût lié au mécanisme d’authentification
proposé (cf. Section 5.5.4).
En revanche, le nombre de requêtes en écriture supporté par un sous-réseau Block-
chain a un impact important sur l’estimation du nombre de sous-réseaux optimal. En
effet, dans notre approche, pour gérer le contrôle d’accès (cf. Section 5.5.5), l’envoi
d’un grand nombre de requêtes en écriture est nécessaire (mise à jour de la position
des équipements terminaux). Il en est de-même pour d’autres approches considérant
l’utilisation de la Blockchain pour générer des pseudonymes, permettant d’assurer la
protection de la vie privée des éléments SD-IoV [LWQ+ 19, LWQL18]. Pour chaque nou-
veau pseudonyme, une requête en écriture serait nécessaire.
Dans le pire des scénarios, une requête en écriture pourrait être envoyée à un sous-
réseau Blockchain à chaque fois qu’un éléments SD-IoV dans ce sous-réseau se connecte
à un équipement de bord de route. Pour notre approche, ce scénario pourrait corres-
pondre à un cas où un contrôleur SDN serait déployé au niveau de chaque équipement
de bord de route. Ainsi, afin d’assurer le contrôle d’accès, la position de l’équipement
terminal devrait être mise à jour à chaque fois que cet équipement se connecte à un
nouvel équipement de bord de route. Pour la protection de la vie privée, ce scénario
correspondrait à une garantie maximale de protection de la vie privée. Ainsi, afin de ga-
rantir l’anonymat et l’intraçabilité des équipements terminaux, un nouveau pseudonyme
serait généré au moment de la connexion à une nouvelle station de base [YCM+ 19].
En considérant ce scénario et en considérant que le nombre maximal de requêtes en
écriture qu’un sous-réseau peut gérer simultanément est égal à 20000, on peut estimer
le nombre minimal de sous-réseaux nécessaires pour la gestion des requêtes en écriture
aux États-Unis en se plaçant dans des conditions extrêmes :
— des équipements de bord de route au faible diamètre : 200m ;
— une densité élevée d’équipements terminaux : 5 000 équipements terminaux par
kilomètre carré, soit 200 équipements terminaux par équipement de bord de
160
route ;
— une vitesse de déplacement des équipements terminaux (notamment véhicules)
élevée : 30 mètres par seconde (la vitesse maximale autorisée sur les autoroutes
aux États-Unis).
Dans ces conditions, le nombre moyen de requêtes en écriture par seconde généré
par chaque équipement de bord de route serait égal à 30 (200/(200/30)). Ainsi, le
nombre maximal de stations de base que pourrait être en mesure de gérer un sous-
réseau Blockchain serait égal à 666 (20 000/30). Par conséquent, considérant que le
nombre d’équipements de bord de route est environ égal à 400 000 aux États-Unis7 ,
dans ce scénario extrême, le nombre minimal de sous-réseaux Blockchain qui devraient
être déployés aux États-Unis serait égal à 600 (400 000/666).
Néanmoins, ce scénario extrême semble peu probable. En effet, il parait peu envisa-
geable qu’un contrôle d’accès des équipements terminaux soit nécessaire au niveau de
chaque équipement de bord de route. Un contrôleur SDN devrait, en théorie, gérer plu-
sieurs équipements de bord de route et non un seul. De même, le niveau de protection
de la vie privée n’est pas nécessairement maximal. Par conséquent, la génération d’un
nouveau certificat n’est pas forcément nécessaire au niveau de chaque équipement de
bord de route [LWQ+ 19, LWQL18]. Aussi, en considérant qu’une zone géographique et
la zone de validité d’un pseudonyme ne correspondent pas à 1 équipement réseau mais
à N équipements réseau, le nombre minimal de sous-réseaux Blockchain pour gérer les
réseaux SD-IoV aux États-Unis serait égal à : 600/N.
L’authentification aux frontières territoriales des États-Unis nécessite également l’en-
voi de requêtes en écriture (ajout de certificats dans le pays voisin : 5.4.3.2). Néanmoins
cette authentification frontalière inter-sous-réseaux Blockchain n’impacte pas l’estima-
tion du nombre optimal de sous-réseaux nécessaires. Pour le prouver, nous pouvons
considérer l’exemple de la frontière entre les États-Unis et le Mexique.
Cette frontière est la plus traversée au monde avec près d’un milliard de véhicules
chaque année, répartis entre 50 postes frontaliers. En supposant que l’ensemble de ces
véhicules doivent être authentifiés à chaque traversée, le nombre moyen de requêtes
par seconde serait égal à 32 (109 /3.154*108 ). On peut supposer que ces requêtes se-
raient réparties, à minima, entre 100 équipements de bord de route (un de chaque
côté de chaque poste frontalier). Ainsi, le nombre moyen de requêtes par seconde par
équipement de bord de route serait inférieur à 1. Par conséquent, l’authentification aux
161
frontières impacte peu le calcul du nombre de sous-réseaux Blockchain (1 < < 20000).
De plus, on peut rajouter que l’authentification inter-sous-réseaux des véhicules traver-
sant cette frontière ne sera pas systématique. En effet, les véhicules déjà enregistrés des
deux côtés de la frontière n’auront plus à l’être. Les véhicules réalisant plusieurs fois le
même trajet ne nécessiteront donc pas de multiples authentifications inter-sous-réseaux,
réduisant encore le nombre de requêtes en écriture nécessaires.
Par conséquent, le nombre minimal de sous-réseaux Blockchain nécessaires pour sé-

curiser les communications SD-IoV dans un pays est conditionné par deux paramètres.
Le premier de ces paramètres est la politique de contrôle d’accès et de protection de
la vie privée mise en place dans ce pays. Le second paramètre est le nombre d’équi-
pements terminaux en circulation dans ce pays. Le nombre maximal de sous-réseaux
Blockchain est lui directement relié aux capacités de la technologie Blockchain consi-
dérée pour le déploiement des mécanismes de sécurité. En effet, comme noté par les
auteurs de [SCS+ 17], les implémentations Blockchain proposées pourraient ne suppor-
ter qu’un nombre de sous-réseaux maximal au delà duquel les performances en termes
d’utilisation de CPU (cf. Section 5.5.5) et de bande passante pourraient être dégradées.
Néanmoins, comme cela est noté par ces mêmes auteurs, dans des conditions optimales
(capacité CPU importante, large bande passante, faible latence), ce nombre maximal de
sous-réseaux peut être perçu comme infini.
Ainsi, le nombre optimal de sous-réseaux Blockchain (optimal_number_of_subnets)

nécessaires pour la sécurisation des communications SD-IoV peut être caractérisé par
deux bornes. Une borne minimale (required_number), correspondant aux nombre mi-
nimal de sous-réseaux Blockchain nécessaires pour la gestion des requêtes en écriture
dans un pays donné. Cette borne minimale peut être évaluée grâce à l’analyse des poli-
tique en place (anonymat, contrôle d’accès, etc.) et des données provenant des équipe-
ments réseau. Une borne maximale (enabled_number), correspondant au nombre maxi-
mal de sous-réseaux supporté par la technologie Blockchain mise en place pour la sé-
curisation des communications SD-IoV dans ce pays. Cette borne maximale peut être
évaluée grâce à une analyse de la technologie Blockchain utilisée. Ainsi :
required_number < optimal_number_of_subnets < enabled_number
162
5.6.2 Résumé
Dans cette section, nous nous sommes intéressés à l’estimation d’un nombre optimal
de sous-réseaux devant permettre le déploiement de notre solution. Pour ce faire, nous
avons considéré l’exemple des États-Unis, un des pays où le plus grand nombre d’équi-
pements terminaux sont en circulation. L’étude menée a pris en compte la capacité des
technologies Blockchain (nombre de requêtes en écriture/lecture, quantité de données
stockable), un scénario (contrôle d’accès/respect de la vie privée) et des conditions
(densité importante, vitesse de déplacement élevée, faible rayon des cellules) extrêmes.
Ceci a permis de définir une borne minimale et une borne maximale pour l’estimation
d’un nombre optimal de sous-réseaux nécessaires à la sécurisation des communications
SD-IoV dans un pays donné. La borne minimale correspond aux nombre minimal de
sous-réseaux Blockchain nécessaires pour la gestion des requêtes en écriture dans ce
pays. La borne maximale correspond au nombre maximal de sous-réseaux supporté par
la technologie Blockchain utilisée dans ce pays.
5.7 Discussion : Bénéfices du plan de connaissance pour

la sécurisation des communications SD-IoV
5.7.1 Bénéfices du plan de connaissance
Dans le chapitre 3, nous avons proposé l’intégration d’un plan de connaissance dans
l’architecture de référence C-ITS (cf. Section 3.5). Les outils d’aide à la prise de déci-
sion (intelligence artificielle, données massives) constituent un élément important de ce
plan. En effet, c’est, notamment, grâce à eux que les performances de l’architecture de
communication pourraient être améliorées (cf. Section 3.5.4.1) : plan de gestion, plan
de contrôle et données, plan de sécurité et de respect de la vie privée.
Aussi, dans cette section, nous définissons quelques applications possibles de ces ou-
tils d’aide à la prise de décision dans le cadre de la sécurisation des interfaces SD-IoV.
Une discussion similaire a été introduite dans le chapitre 4 (cf. Section 4.7.1). Une ana-
lyse croisée de ces deux sections (4.7.1, 5.7.1) est proposée en annexe (cf. Annexe J .).
Cette analyse croisée présente les besoins de traitement communs aux différents plans
de l’architecture C-ITS et démontre ainsi l’intérêt d’un plan de connaissance global.
La solution introduite dans ce chapitre vise à assurer la sécurisation des interfaces
163
SD-IoV grâce à une architecture Blockchain innovante (cf. Section 5.4.2) et des mé-
canismes d’authentification/révocation (cf. Section 5.4.3.2) et de contrôle d’accès (cf.
Section 5.4.3.3) adaptés à cet environnement. Comme nous l’avons noté dans la section
5.6.1, un traitement efficace des données serait nécessaire pour permettre le déploie-
ment de la solution proposée. De même, une analyse de données pourrait permettre
d’améliorer encore le niveau de confiance garanti par cette approche Blockchain. Ainsi,
dans le cadre de la sécurisation des interfaces SD-IoV, le plan de connaissance pourrait
notamment permettre :
— une estimation précise du nombre de sous-réseaux Blockchain devant être
déployés : comme nous l’avons indiqué dans la section 5.6.1, l’estimation du
nombre de sous-réseaux Blockchain devant être déployés dans un pays est directe-
ment dépendante du nombre de requêtes en écriture émises par les équipements
terminaux présents dans cette zone géographique. Or, la mesure de ce nombre
de requêtes pour une zone à la superficie importante (région, pays) nécessite-
rait le traitement de volumes importants de données. Par conséquent, l’utilisation
de techniques de traitement de données massives (Big Data), dans ce contexte,
pourrait permettre une mesure fine du nombre de données générées par les équi-
pements terminaux. Ainsi, le plan de connaissance pourrait permettre d’estimer
précisément le nombre de sous-réseaux Blockchain nécessaires à la sécurisation
des communications dans un pays donné ;
— l’établissement de confiance dans les réseaux SD-IoV : l’approche Blockchain
garantit transparence et sécurité (cf. Section 3.5.3.1). De même, le mécanisme
de contrôle d’accès proposé (cf. Section 5.4.3.3) garantit que seuls des éléments
SD-IoV disposant de privilèges suffisants sont autorisés à communiquer. Toutefois,
la confiance pourrait être renforcée dans les réseaux SD-IoV grâce à une analyse
du comportement des éléments SD-IoV. En effet, cette analyse pourrait permettre
de détecter les éléments SD-IoV malveillants/compromis susceptibles de modi-
fier le comportement du réseau (cf. Section 5.2.1). Dans ce contexte, l’utilisation
de techniques d’intelligence artificielle parait pertinente. Ces techniques (machine
learning, deep learning) pourraient notamment permettre aux noeuds Blockchain
d’analyser le comportement des éléments SD-IoV et de détecter les action anor-
males [SJC19, XDYW19]. Ainsi, un indice de confiance pourrait être attaché à
chaque élément SD-IoV. Cet indice pourrait, ensuite, être utilisé pour limiter la
164
capacité de nuisance des éléments SD-IoV malveillants/compromis [MCK18]. Par

conséquent, dans ce contexte, le plan de connaissance pourrait permettre de ren-
forcer la confiance entre les éléments SD-IoV ;
— la gestion des attaques de type déni de service : l’approche Blockchain (dé-

centralisée), l’architecture considérée (constituée de multiples sous réseaux) et
le mécanisme de contrôle d’accès proposé (limitant les échanges possibles) per-
mettent de limiter les risques d’attaques de déni de service (cf. Section 5.2.1). De
plus, l’établissement de confiance, également considéré dans cette section, pour-
rait encore renforcer le niveau de sécurité de la solution proposée. Néanmoins,
une entité malveillante, contrôlant un nombre important de noeuds SD-IoV, pour-
rait être en mesure de mener une attaque de déni de service distribuée. Dans ce
contexte, l’utilisation de techniques d’intelligence artificielle parait pertinent. En
effet, ces techniques pourraient être utilisées pour détecter ces attaques mais éga-
lement pour leur offrir une réponse [KMM+ 19, LPV+ 19] : redirection du trafic,
passage à l’échelle, etc. Par conséquent, dans ce contexte, le plan de connaissance
pourrait permettre de renforcer la sécurité, notamment pour les attaques de type
déni de service ;
— l’amélioration des performances du réseau Blockchain : l’établissement de

confiance (consensus) et la mise à jour du registre Blockchain reposent sur un
transfert efficace des données entre les noeuds Blockchain composant ce réseau.
Or, la défaillance/panne d’un noeud Blockchain pourrait perturber la répartition
des tâches et la distribution des informations entre les différents noeuds com-
posant ce réseau. Ainsi, les performances du réseau Blockchain pourraient être
dégradées [Li18]. Dans ce contexte, l’utilisation de techniques d’intelligence ar-
tificielle parait pertinente. En effet, ces techniques pourraient être utilisées pour
la détection de ces pannes. Grâce à cette détection, la capacité de transmission
des noeuds Blockchain, la répartition des tâches entre les différents noeuds, et
le temps nécessaire pour valider un bloc de données, pourraient être améliorés
[Li18]. Par conséquent, dans ce contexte, le plan de connaissance pourrait per-
mettre d’améliorer les performances du réseau Blockchain, notamment en cas de
défaillances.
Ainsi, dans ce contexte, l’utilisation du plan de connaissance, défini dans la section
165
3.5.4.1, pourrait présenter de nombreux bénéfices : estimation du nombre de sous-

réseaux Blockchain, établissement de confiance, gestion des attaques de type déni de
service et amélioration des performances du réseau Blockchain.
5.7.2 Résumé
Dans cette section, nous avons cherché à identifier les bénéfices que pourrait ap-
porter le plan de connaissance à la sécurisation des interfaces SD-IoV. Ainsi, nous
avons mis en avant quatre applications du plan de connaissance dans le contexte. Tout
d’abord, l’utilisation des techniques de Big Data pour permettre une estimation précise
du nombre de sous-réseaux Blockchain nécessaires à la sécurisation des communica-
tions SD-IoV. Ensuite, l’utilisation de techniques d’intelligence artificielle pour garantir
un niveau de confiance élevé dans les réseaux SD-IoV. Puis, l’utilisation de techniques
d’intelligence artificielle pour la gestion des attaques de type déni de service. Enfin,
l’utilisation de techniques d’intelligence artificielle pour assurer la détection des noeuds
Blockchain défaillants et améliorer les performances des réseaux Blockchain.
5.8 Conclusion
Dans ce chapitre, nous avons introduit notre troisième contribution : une approche
basée sur la Blockchain garantissant la sécurisation (chiffrement, authentification,
contrôle d’accès) des interfaces SD-IoV.
Pour ce faire, nous avons commencé par identifier les principaux vecteurs d’attaques
existants au niveau des interfaces SD-IoV : déni de service, analyse du réseau, modifi-
cation du réseau. Nous avons, également, mis en avant les bénéfices de la Blockchain
dans ce contexte (cf. Section 5.2.1).
Nous nous sommes, ensuite, intéressés aux travaux existants dans la littérature. Ces
travaux proposent d’utiliser la Blockchain pour sécuriser : l’interface sud (cf. Section
5.3.1), l’interface est/ouest (cf. Section 5.3.2) et l’interface nord (cf. Section 5.3.3). La
comparaison de ces travaux nous a permis de mettre en avant les principales limites des
approches proposées jusqu’ici (cf. Section 5.3.4). Ces limites sont : le manque de passage
à l’échelle, la non considération de l’interface nord et l’absence d’une proposition non
disruptive pour la sécurisation de l’interface est/ouest.
Afin d’y répondre, nous avons par la suite introduit une nouvelle solution visant à
sécuriser les interface SD-IoV (cf. Section 5.4.1). Notre solution s’appuie sur trois évolu-
166
tions principales. La première d’entre elles est la définition d’une nouvelle architecture
Blockchain garantissant un passage à l’échelle important (cf. Section 5.4.2). La seconde
est la proposition de mécanismes d’authentification et de révocation adaptés à cet en-
vironnement et compatibles avec le protocole TLS (cf. Section 5.4.3.2). La dernière est
l’introduction d’un nouveau mécanisme de contrôle d’accès limitant la capacité d’at-
taques des éléments malveillants/compromis (cf. Section 5.4.3.3).
La comparaison de notre solution avec les approches existantes tend à démontrer
ses bénéfices en termes de passage à l’échelle et de sécurité (cf. Section 5.5.5). De plus
les mécanismes d’authentification et révocation (cf. Section 5.5.4) et de contrôle d’accès
(cf. Section 5.5.5) proposés permettent de maintenir des performances acceptables en
termes de débit et latence.
Par la suite, afin de démontrer la faisabilité de la solution considérée, nous nous
sommes penchés sur la question de son déploiement (cf. Section 5.6.1). Pour ce faire,
nous avons considéré l’exemple des États-Unis, un des pays, avec la Chine, où le plus
grand nombre d’équipements terminaux (téléphones portables, véhicules) sont actuel-
lement en circulation. Avec cet exemple, en prenant en compte la capacité des techno-
logies Blockchain, ainsi qu’un scénario et des conditions extrêmes, nous avons été en
mesure de définir un déploiement optimal pour l’architecture Blockchain proposée.
Enfin, nous avons évalués les bénéfices du plan de connaissance (cf. Section 3.5.4.1)
dans le cadre de la sécurisation des interfaces SD-IoV (cf. Section 5.7.1). Ainsi, nous
avons pu mettre en avant quatre applications possibles du plan de connaissance. La pre-
mière d’entre elles est la gestion optimale du déploiement de l’architecture Blockchain
considérée. La seconde est l’établissement de confiance entre les éléments SD-IoV. La
troisième et la gestion des attaques de type déni de service. La dernière est la détection
des noeuds Blockchain défaillants.
167
Chapitre 6
Conclusion et perspectives
Dans cette thèse nous nous sommes focalisés sur la distribution géographique de
données dans l’Internet des Véhicules via l’infrastructure cellulaire. Dans ce chapitre,
nous résumons les principales contributions à ce domaine qui ont été détaillées dans
cette thèse (cf Section 6.1). Nous introduisons, également, quelques perspectives inté-
ressantes qui pourraient être explorées dans des travaux futurs (cf. Section 6.2).
6.1 Principales contributions

Dans le contexte de la distribution géographique de données dans l’Internet des
Véhicules via l’infrastructure cellulaire, notre objectif était de proposer une solution
performante et sécurisée. Les principales contributions sont :
— la définition d’une architecture IoV adaptée aux besoins des applications C-

ITS : cette première contribution correspond à la définition d’une nouvelle archi-
tecture IoV, évolution de l’architecture de référence C-ITS. La définition de cette
architecture s’est basée sur une analyse des besoins des applications C-ITS, des
limites de l’architecture de référence C-ITS et des solutions technologiques envisa-
geables. Le croisement de ces informations a permis de proposer une nouvelle ar-
chitecture adaptée à l’environnement IoV et à la distribution géographique de don-
nées. La solution ainsi conçue s’appuie sur l’intégration de deux éléments princi-
paux au sein de l’architecture de référence. Tout d’abord, un plan de connaissance
devant permettre un traitement efficace et centralisé des données. Ensuite, la tech-
nologie Blockchain devant assurer un niveau de sécurité élevé et un meilleur pas-
sage à l’échelle du plan de sécurité et de respect de la vie privée ;
— la définition, l’implémentation et l’évaluation d’une approche logicielle per-

formante pour la distribution géographique de données : cette seconde contri-
bution correspond à la définition, l’implémentation et l’évaluation d’un protocole
basé sur la technologie SDN pour la distribution géographique de données via l’in-
168
frastructure cellulaire. La solution proposée permet de répondre aux limites du

protocole GeoNet (manque de dynamicité, surcoût) et de gérer efficacement la
mobilité dans un environnement logiciel (canal de contrôle, tables de flux). Elle
repose sur quatre grandes évolutions. Tout d’abord, une prise en compte du niveau
de charge des stations de base dans l’estimation de la durée de vie des connexions
entre les équipements terminaux et les stations de base. Ensuite, une sélection dy-
namique des stations de base destinataires en fonction de la position des équipe-
ments terminaux et du niveau de charge de ces stations de base. Puis, la définition
de machines d’états permettant de gérer la mobilité des équipements terminaux
de façon plus efficace. Enfin, la proposition d’une politique de pré-déploiement
des règles de flux visant à optimiser l’utilisation des ressources à disposition ;
— la définition, l’implémentation et l’évaluation d’une approche basée sur la
Blockchain pour la sécurisation des réseaux SD-IoV : cette troisième contri-
bution correspond à la définition, l’implémentation et l’évaluation d’une solution
basée sur la Blockchain pour la sécurisation des interfaces de communication des
réseaux véhiculaires définis logiciellement. La solution proposée permet de ré-
pondre aux limites des solutions actuelles : manque de passage à l’échelle et ab-
sence de sécurisation des interfaces est/ouest et nord. Elle repose sur trois évo-
lutions principales. Tout d’abord, la définition d’une nouvelle architecture Blo-
ckchain garantissant le passage à l’échelle. Ensuite, la définition de mécanismes
d’authentification et de révocation basés sur la Blockchain et compatibles avec le
protocole TLS. Enfin, la proposition d’un nouveau mécanisme de contrôle d’ac-
cès limitant la capacité d’attaques des éléments SD-IoV malveillants/compromis.
Bien qu’étudiée dans le contexte des réseaux SD-IoV, l’approche définie pourrait
permettre une sécurisation des réseaux IoV dans leur ensemble.
6.2 Perspectives et nouveaux défis

Les travaux introduits dans cette thèse contribuent à l’amélioration de la distribution
géographique des données dans l’Internet des Véhicules. Cependant, ces travaux ne per-
mettent pas de répondre à l’ensemble des problématiques posées par cette distribution
géographique de données. Plusieurs perspectives peuvent ainsi être identifiées :
— l’implémentation et l’évaluation du plan de connaissance : dans le Chapitre 3,
nous avons proposé la définition d’un plan de connaissance global, commun à l’en-
169
semble des plans de l’architecture de communication IoV. Nous avons, ensuite, dé-
montré les bénéfices de ce plan pour la distribution géographique de données (cf.
Section 4.7.1) et la sécurisation des communications SD-IoV (cf. Section 5.7.1).
Dans ces deux contextes, le fonctionnement du plan de connaissance repose sur
la remontée d’informations provenant de mêmes sources (cf. Annexe J .) : véhi-
cules, stations de base, contrôleurs SDN, etc. De plus, de nombreuses applications
du plan de connaissance pourraient être bénéfiques tant pour la distribution de
données que pour la sécurisation des communications. C’est, notamment, le cas
de la prédiction de mobilité des véhicules, de l’estimation du niveau de charge des
stations de base ou de l’établissement de confiance. La définition d’un plan global
de connaissance garantirait donc un traitement efficace des données, simplifiant
la remontée de informations, évitant la duplication de tâches de pré-traitement
et offrant des services communs aux différents plans de l’architecture C-ITS. C’est
pourquoi, l’implémentation et l’évaluation de ce plan de connaissance apparaît
comme une perspective intéressante. Il semblerait, notamment, pertinent d’éva-
luer, dans un environnement réel, son impact tant en terme de performances que
de surcoût (calcul, stockage, communications) ;
— le développement de solutions basées sur l’intelligence artificielle pour la
prédiction du niveau de charge des stations de base : comme nous l’avons
démontré dans le chapitre 4, en prenant en compte le niveau de charge des sta-
tions de base, les ressources réseau pourraient être utilisées plus efficacement. Il
pourrait être également intéressant de considérer les outils actuellement utilisés
pour la prédiction. En effet, grâce aux techniques d’intelligence artificielle, une
prédiction fine de la capacité des stations de base et une utilisation optimale des
ressources réseaux pourraient être possible ;
— la définition d’un plan de données avec états au niveau des équipements
terminaux : dans le chapitre 4, nous avons démontré qu’un plan de données
avec états pourrait permettre une meilleure gestion de la mobilité au niveau
de l’infrastructure cellulaire. Aussi, il semblerait pertinent de considérer le dé-
ploiement d’un plan de données avec états au niveau des équipements termi-
naux. Ceci pourrait permettre une gestion dynamique et efficace des communi-
cations directs Objet-à-Objet. Le développement d’une telle solution nécessiterait
d’adapter le plan de données avec états à un environnement hautement mobile
170
(connexions/déconnexions encore plus fréquentes) aux ressources limitées (tables

de flux) ;
— l’étude du déploiement des contrôleurs SDN : la solution proposée dans le cha-
pitre 4 repose sur l’utilisation d’un plan de contrôle distribué. Or, la gestion de ce
plan de contrôle distribué constitue aujourd’hui un enjeu majeur. En effet, afin de
garantir la performance de l’approche logicielle, il est nécessaire de gérer effica-
cement les ressources allouées (stockage, calcul, communication) aux contrôleurs
SDN. De même, la répartition de charge entre les contrôleurs SDN et l’allocation
de zones géographiques à chacun des contrôleurs SDN constituent des axes de
recherche importants. Aussi, dans le cadre de l’approche proposée, il semblerait
pertinent d’étudier le déploiement des contrôleurs SDN ;
— l’établissement de confiance dans les réseaux véhiculaires : comme nous
l’avons noté dans le chapitre 5, l’authentification et le contrôle d’accès des élé-
ments SD-IoV ne sont qu’une première étape en vue de la sécurisation des com-
munications véhiculaires. En effet, contrôler les messages échangés entre les élé-
ments SD-IoV et contrôler le comportement de ces éléments constitue un enjeu
majeur. Aussi, il semblerait pertinent de développer et d’évaluer des mécanismes
basés sur la Blockchain pour établir la confiance entre les éléments SD-IoV. Nous
pourrions, notamment, envisager l’implémentation de la solution que nous avons
introduite dans [MCK18] ;
— une gestion plus efficace des registres Blockchain : l’approche proposée dans
le chapitre 5 nécessite un nombre d’écritures/lectures dans le registre Blockchain
important, notamment pour le contrôle d’accès. Pour améliorer encore le pas-
sage à l’échelle, il pourrait être intéressant d’étudier l’utilisation de State Chan-
nels [MBB+ 19]. Il s’agit d’une application de la technologie Blockchain permettant
d’établir des communications directes entre clients Blockchain. Ainsi, le nombre
d’écritures dans le registre Blockchain pourrait être limité et la capacité du ré-
seau Blockchain augmentée. Le développement d’une telle solution nécessiterait
d’adapter ces State Channels à un environnement mobile où les connexions entre
clients Blockchain ne sont pas nécessairement continues.
171
172
Bibliographie
[A+ 09] Kevin Ashton et al. That ‘internet of things’ thing. RFID journal,
22(7) :97–114, 2009.
[AA15] Nasser M Alotaibi and Sami S Alwakeel. A neural network based hando-
ver management strategy for heterogeneous networks. In 2015 IEEE 14th
international conference on machine learning and applications (ICMLA),
pages 1210–1214. IEEE, 2015.
[AAK+ 18] Ahmed Aliyu, Abdul Hanan Abdullah, Omprakash Kaiwartya, Yue Cao,
Mohammed Joda Usman, Sushil Kumar, DK Lobiyal, and Ram Shringar
Raw. Cloud computing in vanets : architecture, taxonomy, and chal-
lenges. IETE Technical Review, 35(5) :523–547, 2018.
[ABA17] Aliyu Lawal Aliyu, Peter Bull, and Ali Abdallah. A trust management fra-
mework for network applications within an SDN environment. In 31st
International Conference on Advanced Information Networking and Appli-
cations Workshops, AINA 2017 Workshops, Taipei, Taiwan, March 27-29,
2017, pages 93–98. IEEE, 2017.
[ABB+ 18] Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstan-
tinos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gen-
nady Laventman, Yacov Manevich, et al. Hyperledger fabric : a distribu-
ted operating system for permissioned blockchains. In Proceedings of the
Thirteenth EuroSys Conference, pages 1–15, 2018.
[ACS18] Daniyal Amir Awan, Renato LG Cavalcante, and Slawomir Stanczak. A

robust machine learning method for cell-load approximation in wireless
networks. In 2018 IEEE International Conference on Acoustics, Speech and
Signal Processing (ICASSP), pages 2601–2605. IEEE, 2018.
173
Bibliographie
[AHZI+ 20] Othman S Al-Heety, Zahriladha Zakaria, Mahamod Ismail, Moham-

med Mudhafar Shakir, Sameer Alani, and Hussein Alsariera. A compre-
hensive survey : Benefits, services, recent works, challenges, security, and
use cases for sdn-vanet. IEEE Access, 8 :91028–91047, 2020.
[AK17] Abdul Ghafoor Abbasi and Zaheer Khan. Veidblock : Verifiable identity
using blockchain and ledger in a software defined network. In Compa-
nion Proceedings of the10th International Conference on Utility and Cloud
Computing, pages 173–179, 2017.
[AKM17] Justice Owusu Agyemang, Jerry John Kponyo, and Joseph Mouzna. Light
fidelity (lifi) as an alternative data transmission medium in vanet. In
2017 European Modelling Symposium (EMS), pages 213–217. IEEE, 2017.
[AMS+ 14] José Javier Anaya, Pierre Merdrignac, Oyunchimeg Shagdar, Fawzi Na-
shashibi, and José E Naranjo. Vehicle to pedestrian communications for
protection of vulnerable road users. In 2014 IEEE Intelligent Vehicles Sym-
posium Proceedings, pages 1037–1042. IEEE, 2014.
[AMS20] Muhammad Tahir Abbas, Afaq Muhammad, and Wang-Cheol Song. Sd-
iov : Sdn enabled routing for internet of vehicles in road-aware approach.
Journal of Ambient Intelligence and Humanized Computing, 11(3) :1265–
1280, 2020.
[ANLC16] Ian F Akyildiz, Shuai Nie, Shih-Chun Lin, and Manoj Chandrasekaran. 5g
roadmap : 10 key enabling technologies. Computer Networks, 106 :17–
48, 2016.
[ARD18] Igor D Alvarenga, Gabriel AF Rebello, and Otto Carlos MB Duarte. Secu-
ring configuration management and migration of virtual network func-
tions using blockchain. In NOMS 2018-2018 IEEE/IFIP Network Opera-
tions and Management Symposium, pages 1–9. IEEE, 2018.
[ASA+ 15] K Ashokkumar, Baron Sam, R Arshadprabhu, et al. Cloud based intelli-
gent transport system. Procedia Computer Science, 50 :58–63, 2015.
174
Bibliographie
[ASABZ13] Saif Al-Sultan, Ali H Al-Bayatti, and Hussein Zedan. Context-aware dri-
ver behavior detection system in intelligent transportation systems. IEEE
transactions on vehicular technology, 62(9) :4264–4275, 2013.
[ASV17] Belema Agborubere and Erika Sanchez-Velazquez. Openflow communi-

cations and tls security in software-defined networks. In 2017 IEEE Inter-
national Conference on Internet of Things (iThings) and IEEE Green Compu-
ting and Communications (GreenCom) and IEEE Cyber, Physical and Social
Computing (CPSCom) and IEEE Smart Data (SmartData), pages 560–566.
IEEE, 2017.
[AWG+ 20] Muhammad Arif, Guojun Wang, Oana Geman, Valentina Emilia Balas,
Peng Tao, Adrian Brezulianu, and Jianer Chen. Sdn-based vanets, secu-
rity attacks, applications, and challenges. Applied Sciences, 10(9) :3217,
2020.
[AX14] Anand V Akella and Kaiqi Xiong. Quality of service (qos)-guaranteed

network resource allocation via software defined networking (sdn). In
2014 IEEE 12th International Conference on Dependable, Autonomic and
Secure Computing, pages 7–13. IEEE, 2014.
[B+ 14] Vitalik Buterin et al. A next-generation smart contract and decentralized
application platform. white paper, 3(37), 2014.
[BBEK11] Michael Behrisch, Laura Bieker, Jakob Erdmann, and Daniel Krajzewicz.
Sumo–simulation of urban mobility : an overview. In Proceedings of SI-
MUL 2011, The Third International Conference on Advances in System Si-
mulation. ThinkMind, 2011.
[BBSA14] Gaurav Bora, Saurabh Bora, Shivendra Singh, and Sheikh Mohamad Ar-
salan. Osi reference model : An overview. International Journal of Com-
puter Trends and Technology (IJCTT), 7(4) :214–218, 2014.
175
Bibliographie
[BC15] Elif Bozkaya and Berk Canberk. Qoe-based flow management in soft-
ware defined vehicular networks. In 2015 IEEE Globecom Workshops (GC
Wkshps), pages 1–6. IEEE, 2015.
[BCC17] Tugce Bilen, Berk Canberk, and Kaushik R Chowdhury. Handover ma-
nagement in software-defined ultra-dense 5g networks. IEEE Network,
31(4) :49–55, 2017.
[BFG+ 17] Bego Blanco, Jose Oscar Fajardo, Ioannis Giannoulakis, Emmanouil Ka-
fetzakis, Shuping Peng, Jordi Pérez-Romero, Irena Trajkovska, Pouria S
Khodashenas, Leonardo Goratti, Michele Paolino, et al. Technology pillars
in the architecture of future 5g mobile networks : Nfv, mec and sdn. Com-
puter Standards & Interfaces, 54 :216–228, 2017.
[BGR19] Sarra Boukria, Mohamed Guerroumi, and Imed Romdhani. Bcfr :

Blockchain-based controller against false flow rule injection in sdn. In
2019 IEEE Symposium on Computers and Communications (ISCC), pages
1034–1039. IEEE, 2019.
[BKT15] Stéphane Betgé-Brezetz, Guy-Bertrand Kamga, and Monsef Tazi. Trust

support for sdn controllers and virtualized network applications. In Pro-
ceedings of the 1st IEEE Conference on Network Softwarization, NetSoft
2015, London, United Kingdom, April 13-17, 2015, pages 1–5. IEEE, 2015.
[BM12] Salim Bitam and Abdelhamid Mellouk. Its-cloud : Cloud computing for
intelligent transportation system. In 2012 IEEE global communications
conference (GLOBECOM), pages 2054–2059. IEEE, 2012.
[BMO16] Samaresh Bera, Sudip Misra, and Mohammad S Obaidat. Mobility-aware

flow-table implementation in software-defined iot. In 2016 IEEE Global
Communications Conference (GLOBECOM), pages 1–6. IEEE, 2016.
[BMO18] Samaresh Bera, Sudip Misra, and Mohammad S Obaidat. Mobi-flow :

Mobility-aware adaptive flow-rule placement in software-defined access
176
Bibliographie
network. IEEE Transactions on Mobile Computing, 18(8) :1831–1842,

2018.
[BOV17] Eugen Borcoci, Serban Obreja, and Marius Vochin. Internet of vehicles
functional architectures-comparative critical study. In The Ninth Inter-
national Conference on Advances in Future Internet, AFIN, pages 10–14,
2017.
[BSAR15] Abbas Bradai, Kamal Singh, Toufik Ahmed, and Tinku Rasheed. Cellular
software defined networking : a framework. IEEE communications maga-
zine, 53(6) :36–43, 2015.
[BSM18] Fetia Bannour, Sami Souihi, and Abdelhamid Mellouk. Distributed sdn
control : Survey, taxonomy, and challenges. IEEE Communications Surveys
& Tutorials, 20(1) :333–354, 2018.
[BSN14] Mehrdad Bagheri, Matti Siekkinen, and Jukka K Nurminen. Cellular-

based vehicle to pedestrian (v2p) adaptive communication for collision
avoidance. In 2014 international conference on connected vehicles and expo
(ICCVE), pages 450–456. IEEE, 2014.
[BSV+ 18] Arati Baliga, Nitesh Solanki, Shubham Verekar, Amol Pednekar, Pandu-
rang Kamat, and Siddhartha Chatterjee. Performance characterization of
hyperledger fabric. In 2018 Crypto Valley Conference on Blockchain Tech-
nology (CVCBT), pages 65–74. IEEE, 2018.
[CA14] Mahima Chitkara and Mohd Waseem Ahmad. Review on manet : cha-
racteristics, challenges, imperatives and routing protocols. International
journal of computer science and mobile computing, 3(2) :432–437, 2014.
[Cat09] Daniele Catteddu. Cloud computing : benefits, risks and recommenda-

tions for information security. In Iberic Web Application Security Confe-
rence, pages 17–17. Springer, 2009.
177
Bibliographie
[CBM17] Sergio Correia, Azzedine Boukerche, and Rodolfo I Meneguette. An archi-

tecture for hierarchical software-defined vehicular networks. IEEE Com-
munications Magazine, 55(7) :80–86, 2017.
[CCZGI17a] Juan Contreras-Castillo, Sherali Zeadally, and Juan Antonio Guerrero-

Ibañez. Internet of vehicles : architecture, protocols, and security. IEEE
Internet of Things Journal, 5(5) :3701–3709, 2017.
[CCZGI17b] Juan Contreras-Castillo, Sherali Zeadally, and Juan Antonio Guer-

rero Ibáñez. A seven-layered model architecture for internet of vehicles.
Journal of Information and Telecommunication, 1(1) :4–22, 2017.
[CHC16] Pierpaolo Cincilla, Omar Hicham, and Benoit Charles. Vehicular pki
scalability-consistency trade-offs in large scale distributed scenarios. In
2016 IEEE Vehicular Networking Conference (VNC), pages 1–8. IEEE, 2016.
[CHS+ 17] Shanzhi Chen, Jinling Hu, Yan Shi, Ying Peng, Jiayi Fang, Rui Zhao, and
Li Zhao. Vehicle-to-everything (v2x) services supported by lte-based sys-
tems and 5g. IEEE Communications Standards Magazine, 1(2) :70–76,
2017.
[CMIM17] Claudia Campolo, Antonella Molinaro, Antonio Iera, and Francesco Meni-
chella. 5g network slicing for vehicle-to-everything services. IEEE Wireless
Commun., 24(6) :38–45, 2017.
[CMJ+ 18] Min Chen, Yiming Miao, Xin Jian, Xiaofei Wang, and Iztok Humar.
Cognitive-lpwan : Towards intelligent wireless services in hybrid low po-
wer wide area networks. IEEE Transactions on Green Communications and
Networking, 3(2) :409–417, 2018.
[Com15] Fog Computing. the internet of things : Extend the cloud

to where the things are. Available on : http ://www. cisco.
com/c/dam/en_us/solutions/trends/iot/docs/computingoverview. pdf,
2015.
178
Bibliographie
[CPSC15] Carmelo Cascone, Luca Pollini, Davide Sanvito, and Antonio Capone.
Traffic management applications for stateful sdn data plane. In 2015
Fourth European Workshop on Software Defined Networks, pages 85–90.
IEEE, 2015.
[CRDP19] Maurantonio Caprolu, Simone Raponi, and Roberto Di Pietro. Fortress :

an efficient and distributed firewall for stateful data plane sdn. Security
and Communication Networks, 2019, 2019.
[CSP+ 17] Carmelo Cascone, Davide Sanvito, Luca Pollini, Antonio Capone, and
Brunilde Sanso. Fast failure detection and recovery in sdn with stateful
data plane. International Journal of Network Management, 27(2) :e1957,
2017.
[CTF+ 18] Min Chen, Yuanwen Tian, Giancarlo Fortino, Jing Zhang, and Iztok Hu-
mar. Cognitive internet of vehicles. Computer Communications, 120 :58–
70, 2018.
[CWWL18] Tao Cheng, Kuochen Wang, Li-Chun Wang, and Chain-Wu Lee. An in-
switch rule caching and replacement algorithm in software defined net-
works. In 2018 IEEE International Conference on Communications (ICC),
pages 1–6. IEEE, 2018.
[DKC+ 17] Marc C Dacier, Hartmut König, Radoslaw Cwalinski, Frank Kargl, and
Sven Dietrich. Security challenges and opportunities of software-defined
networking. IEEE Security & Privacy, 15(2) :96–100, 2017.
[DKS+ 18] Joao M Duarte, Eirini Kalogeiton, Ridha Soua, Gaetano Manzo, Ma-
ria Rita Palattella, Antonio Di Maio, Torsten Braun, Thomas Engel, Lean-
dro A Villas, and Gianluca A Rizzo. A multi-pronged approach to adaptive
and context aware content dissemination in vanets. Mobile Networks and
Applications, 23(5) :1247–1259, 2018.
[DLOX15] Mianxiong Dong, He Li, Kaoru Ota, and Jiang Xiao. Rule caching in sdn-
enabled mobile access networks. IEEE Network, 29(4) :40–45, 2015.
179
Bibliographie
[DPS18] Erik Dahlman, Stefan Parkvall, and Johan Skold. 5G NR : The next gene-
ration wireless access technology. Academic Press, 2018.
[dSdCS+ 18] Roniel S de Sousa, Felipe S da Costa, Andre CB Soares, Luiz FM Vieira,
and Antonio AF Loureiro. Geo-sdvn : A geocast protocol for software
defined vehicular networks. In 2018 IEEE International Conference on
Communications (ICC), pages 1–6. IEEE, 2018.
[DSG19] Tamal Das, Vignesh Sridharan, and Mohan Gurusamy. A survey on

controller placement in sdn. IEEE Communications Surveys & Tutorials,
22(1) :472–503, 2019.
[DT18] Thang N Dinh and My T Thai. Ai and blockchain : A disruptive integra-

tion. Computer, 51(9) :48–53, 2018.
[Dug10] Jon Dugan. Iperf tutorial. Columbus : Summer JointTechs, pages 1–4,
2010.
[DWLZ16] Xiaoyu Duan, Xianbin Wang, Yanan Liu, and Kan Zheng. Sdn enabled
dual cluster head selection and adaptive clustering in 5g-vanet. In 2016
IEEE 84th Vehicular Technology Conference (VTC-Fall), pages 1–5. IEEE,
2016.
[DZ16] Lobna Dridi and Mohamed Faten Zhani. Sdn-guard : Dos attacks mitiga-
tion in sdn networks. In 2016 5th IEEE International Conference on Cloud
Networking (Cloudnet), pages 212–217. IEEE, 2016.
[ETS14] ETSI. Mobile-edge computing. Introductory Technical White Paper, 2014.
[ETS17] ETSI. Multi-access edge computing. Developing Software for Multi-Access

Edge Computing, 2017.
[EZCD14] Nicole El Zoghby, Véronique Cherfaoui, and Thierry Denoeux. Evidential

distributed dynamic map for cooperative perception in vanets. In 2014
IEEE Intelligent Vehicles Symposium Proceedings, pages 1421–1426. IEEE,
2014.
180
Bibliographie
[FAB+ 15] Ramon R Fontes, Samira Afzal, Samuel HB Brito, Mateus AS Santos, and
Christian Esteve Rothenberg. Mininet-wifi : Emulating software-defined
wireless networks. In 2015 11th International Conference on Network and
Service Management (CNSM), pages 384–389. IEEE, 2015.
[FCZ+ 19] Daquan Feng, Bin Cao, Zhenghui Zhang, Shengli Zhang, Lei Zhang, Mu-
gen Peng, and Yun Li. Performance analysis and comparison of pow, pos
and dag based blockchains. Digital Communications and Networks, 2019.
[Fes14] Andreas Festag. Cooperative intelligent transport systems standards in

europe. IEEE communications magazine, 52(12) :166–172, 2014.
[FF17] AE Fernandez and M Fallgren. 5gcar scenarios, use cases, requirements

and kpis. Fifth Generation Communication Automotive Research and inno-
vation, Tech. Rep. D, 2, 2017.
[GA17] Solomon T Girma and Abinet G Abebe. Mobility load balancing in cellular
system with multicriteria handoff algorithm. Advances in Fuzzy Systems,
2017, 2017.
[GL17] Yangshui Gao and Tao Luo. A load balancing scheme for supporting safety
applications in heterogeneous software defined lte-v networks. In 2017
IEEE 28th Annual International Symposium on Personal, Indoor, and Mobile
Radio Communications (PIMRC), pages 1–5. IEEE, 2017.
[GLGK19] Christian Gorenflo, Stephen Lee, Lukasz Golab, and Srinivasan Keshav.
Fastfabric : Scaling hyperledger fabric to 20,000 transactions per second.
In 2019 IEEE International Conference on Blockchain and Cryptocurrency
(ICBC), pages 455–463. IEEE, 2019.
[GMS+ 18] Dennis Grewe, Claudio Marxer, Christopher Scherb, Marco Wagner, and
Christian Tschudin. A network stack for computation-centric vehicular
networking. In Proceedings of the 5th ACM Conference on Information-
Centric Networking, pages 208–209, 2018.
181
Bibliographie
[GPR+ 19] Marco Giordani, Michele Polese, Arnab Roy, Douglas Castor, and Michele
Zorzi. Standalone and non-standalone beam management for 3gpp nr at
mmwaves. IEEE Communications Magazine, 57(4) :123–129, 2019.
[GYHX18] Aipeng Guo, Chunhui Yuan, Gang He, and Lexi Xu. Research on sdn/nfv
network traffic management and optimization based on big data and ar-
tificial intelligence. In 2018 18th International Symposium on Communi-
cations and Information Technologies (ISCIT), pages 377–382. IEEE, 2018.
[GZ16] Dalong Guo and Chi Zhou. Potential performance analysis and future
trend prediction of electric vehicle with v2g/v2h/v2b capability. AIMS
Energy, 4(22) :331–346, 2016.
[HKMVM16] Choong Seon Hong, SM Ahsan Kazmi, Seungil Moon, and Nguyen
Van Mui. Sdn based wireless heterogeneous network management. In
AETA 2015 : Recent Advances in Electrical Engineering and Related Sciences,
pages 3–12. Springer, 2016.
[HLC+ 16] Xueshi Hou, Yong Li, Min Chen, Di Wu, Depeng Jin, and Sheng Chen.
Vehicular fog computing : A viewpoint of vehicles as the infrastructures.
IEEE Transactions on Vehicular Technology, 65(6) :3860–3873, 2016.
[HPL+ 13] Kiryong Ha, Padmanabhan Pillai, Grace A. Lewis, Soumya Simanta, Sarah
Clinch, Nigel Davies, and Mahadev Satyanarayanan. The impact of mo-
bile multimedia applications on data center consolidation. In 2013 IEEE
International Conference on Cloud Engineering, IC2E 2013, San Francisco,
CA, USA, March 25-27, 2013, pages 166–176, 2013.
[HVIP15] Enrique Hernandez-Valencia, Steven Izzo, and Beth Polonsky. How will
nfv/sdn transform service provider opex ? IEEE Network, 29(3) :60–67,
2015.
[HYZ+ 16] Ying He, Fei Richard Yu, Nan Zhao, Hongxi Yin, Haipeng Yao, and Ro-
bert C Qiu. Big data analytics in mobile cellular networks. IEEE access,
4 :1985–1996, 2016.
182
Bibliographie
[IKLK17] Bassey Isong, Tebogo Kgogo, Francis Lugayizi, and Bennett Kankuzi.
Trust establishment framework between sdn controller and applications.
In 18th IEEE/ACIS International Conference on Software Engineering, Ar-
tificial Intelligence, Networking and Parallel/Distributed Computing, SNPD
2017, Kanazawa, Japan, June 26-28, 2017, pages 101–107. IEEE, 2017.
[IVP14] Sofiane Imadali, Véronique Vèque, and Alexandru Petrescu. Analyzing

dynamic ipv6 address auto-configuration techniques for group ip-based
vehicular communications. In 39th Annual IEEE Conference on Local Com-
puter Networks Workshops, pages 722–729. IEEE, 2014.
[JCL19] Wafa Ben Jaballah, Mauro Conti, and Chhagan Lal. A survey on software-
defined vanets : benefits, challenges, and future directions. arXiv preprint
arXiv :1904.04577, 2019.
[JHN+ 16] Chen Jiacheng, ZHOU Haibo, Zhang Ning, Yang Peng, Gui Lin, and Shen
Xuemin. Software defined internet of vehicles : Architecture, challenges
and solutions. Journal of communications and information networks,
1(1) :14–26, 2016.
[JZH+ 14] Michael Jarschel, Thomas Zinner, Tobias Hoßfeld, Phuoc Tran-Gia, and
Wolfgang Kellerer. Interfaces, attributes, and use cases : A compass for
sdn. IEEE Communications Magazine, 52(6) :210–217, 2014.
[KAC+ 16] Omprakash Kaiwartya, Abdul Hanan Abdullah, Yue Cao, Ayman Alta-
meem, Mukesh Prasad, Chin-Teng Lin, and Xiulei Liu. Internet of ve-
hicles : Motivation, layered architecture, network model, challenges, and
future aspects. IEEE Access, 4 :5356–5373, 2016.
[KD17] Murat Karakus and Arjan Durresi. A survey : Control plane scalability
issues and approaches in software-defined networking (sdn). Computer
Networks, 112 :279–293, 2017.
183
Bibliographie
[KDDP18] Manzoor A Khan, Xuan T Dang, Tobias Doersch, and Sebastian Peters.
Mobility management approaches for sdn-enabled mobile networks. An-
nals of Telecommunications, 73(11-12) :719–731, 2018.
[KIAM17] Tebogo Kgogo, Bassey Isong, and Adnan M Abu-Mahfouz. Software defi-
ned wireless sensor networks security challenges. In 2017 IEEE AFRICON,
pages 1508–1513. IEEE, 2017.
[KKM19] Murat Yasin Kubilay, Mehmet Sabir Kiraz, and Hacı Ali Mantar. Certled-
ger : A new pki model with certificate transparency based on blockchain.
Computers & Security, 85 :333–352, 2019.
[KKZ18] Vasiliy Krundyshev, Maxim Kalinin, and Peter Zegzhda. Artificial swarm
algorithm for vanet protection against routing attacks. In 2018 IEEE In-
dustrial Cyber-Physical Systems (ICPS), pages 795–800. IEEE, 2018.
[KLBLa18] Hamza Khan, Petri Luoto, Mehdi Bennis, and Matti Latva-aho. On the
application of network slicing for 5g-v2x. In European Wireless 2018 ;
24th European Wireless Conference, pages 1–6. VDE, 2018.
[KLH15] Dongkyu Kim, Haesoon Lee, and Daesik Hong. A survey of in-band full-
duplex transmission : From the perspective of phy and mac layers. IEEE
Communications Surveys & Tutorials, 17(4) :2017–2046, 2015.
[KMM+ 19] Bashar Ahmed Khalaf, Salama A Mostafa, Aida Mustapha, Mazin Abed
Mohammed, and Wafaa Mustafa Abduallah. Comprehensive review of
artificial intelligence and statistical approaches in distributed denial of
service attack and defense methods. IEEE Access, 7 :51691–51713, 2019.
[KP15] Mohammad Khodaei and Panos Papadimitratos. The key to intelligent

transportation : Identity and credential management in vehicular com-
munication systems. IEEE Vehicular Technology Magazine, 10(4) :63–69,
2015.
[KR15] Asif Uddin Khan and Bikram Kesari Ratha. Time series prediction qos
routing in software defined vehicular ad-hoc network. In 2015 Interna-
184
Bibliographie
tional Conference on Man and Machine Interfacing (MAMI), pages 1–6.

IEEE, 2015.
[KS19] Ahmed Jawad Kadhim and Seyed Amin Hosseini Seno. Energy-efficient
multicast routing protocol based on sdn and fog computing for vehicular
networks. Ad Hoc Networks, 84 :68–81, 2019.
[Kuk13] P Kukolev. Comparison of 802.11 a and 802. 11p over fading channels.
Elektrorevue, 4(1) :7–11, 2013.
[LCC15] Yu-Chun Liu, Chien Chen, and Suchandra Chakraborty. A software defi-
ned network architecture for geobroadcast in vanets. In 2015 IEEE Inter-
national Conference on Communications (ICC), pages 6559–6564. IEEE,
2015.
[LETM14] Erik G Larsson, Ove Edfors, Fredrik Tufvesson, and Thomas L Marzetta.
Massive mimo for next generation wireless systems. IEEE communications
magazine, 52(2) :186–195, 2014.
[LHJ17] Harashta Tatimma Larasati, Rifqy Hakimi, and Tutun Juhana. Extended-
llf : A least loaded first (llf)-based handover association control for
software-defined wireless network. International Journal of Computer En-
gineering and Information Technology, 9(9) :203, 2017.
[LHLS17] Ji Lianghai, Bin Han, Man Liu, and Hans D Schotten. Applying device-
to-device communication to enhance iot services. IEEE Communications
Standards Magazine, 1(2) :85–91, 2017.
[Li18] Jiao Li. Data transmission scheme considering node failure for block-
chain. Wireless Personal Communications, 103(1) :179–194, 2018.
[LJP03] Hong-Yon Lach, Christophe Janneteau, and Alexandru Petrescu. Net-

work mobility in beyond-3g systems. IEEE Communications Magazine,
41(7) :52–57, 2003.
[LLLO16] Jun Huy Lam, Sang-Gon Lee, Hoon-Jae Lee, and Yustus Eko Oktian. Tls
channel implementation for onos’s east/west-bound communication. In
185
Bibliographie
Electronics, Communications and Networks V, pages 397–403. Springer,

2016.
[LMLA20] Wenjuan Li, Weizhi Meng, Zhiqiang LIU, and Man-Ho Au. Towards
blockchain-based software-defined networking : Security challenges and
solutions. Ieice Transactions on Information and Systems, 103(2) :196–
203, 2020.
[LPS+ 16] Sven Laux, Gurjashan Singh Pannu, Stefan Schneider, Jan Tiemann, Flo-
rian Klingler, Christoph Sommer, and Falko Dressler. Openc2x—an open
source experimental and prototyping platform supporting etsi its-g5. In
2016 IEEE Vehicular Networking Conference (VNC), pages 1–2. IEEE, 2016.
[LPV+ 19] J Lekha, G Padmavathi, AS Vimal, S Shijumon, and K Lakshanaa. A com-

prehensive study on machine learning and optimization methods to mi-
tigate denial of service attacks in hybrid intrusion detection system. In
2019 International Conference on Intelligent Sustainable Systems (ICISS),
pages 610–615. IEEE, 2019.
[LS16] Chanhee Lee and Seungwon Shin. Shield : an automated framework for
static analysis of sdn applications. In Proceedings of the 2016 ACM Inter-
national Workshop on Security in Software Defined Networks & Network
Function Virtualization, pages 29–34, 2016.
[LS18] Wei Liu and Yozo Shoji. Applying deep recurrent neural network to
predict vehicle mobility. In 2018 IEEE Vehicular Networking Conference
(VNC), pages 1–6. IEEE, 2018.
[LWQ+ 19] Zhaojun Lu, Qian Wang, Gang Qu, Haichun Zhang, and Zhenglin Liu.
A blockchain-based privacy-preserving authentication scheme for va-
nets. IEEE Transactions on Very Large Scale Integration (VLSI) Systems,
27(12) :2792–2801, 2019.
[LWQL18] Zhaojun Lu, Qian Wang, Gang Qu, and Zhenglin Liu. Bars : a blockchain-
based anonymous reputation system for trust management in vanets. In
186
Bibliographie
2018 17th IEEE International Conference On Trust, Security And Privacy In

Computing And Communications/12th IEEE International Conference On
Big Data Science And Engineering (TrustCom/BigDataSE), pages 98–103.
IEEE, 2018.
[LZZ+ 17] Rongpeng Li, Zhifeng Zhao, Xuan Zhou, Guoru Ding, Yan Chen, Zhon-
gyao Wang, and Honggang Zhang. Intelligent 5g : When cellular
networks meet artificial intelligence. IEEE Wireless Communications,
24(5) :175–183, 2017.
[Mäk15] Olli Mäkinen. Streaming at the edge : Local service concepts utilizing
mobile edge computing. In 2015 9th International Conference on Next Ge-
neration Mobile Applications, Services and Technologies, pages 1–6. IEEE,
2015.
[MALP11] Zeinab Movahedi, Mouna Ayari, Rami Langar, and Guy Pujolle. A survey
of autonomic network architectures and evaluation criteria. IEEE Com-
munications Surveys & Tutorials, 14(2) :464–490, 2011.
[MBB+ 19] Patrick McCorry, Surya Bakshi, Iddo Bentov, Sarah Meiklejohn, and An-
drew Miller. Pisa : Arbitration outsourcing for state channels. In Pro-
ceedings of the 1st ACM Conference on Advances in Financial Technologies,
pages 16–30, 2019.
[MCK18] Léo Mendiboure, Mohamed Aymen Chalouf, and Francine Krief. Towards
a blockchain-based sd-iov for applications authentication and trust ma-
nagement. In International Conference on Internet of Vehicles, pages 265–
277. Springer, 2018.
[MCK19a] Leo Mendiboure, Mohamed-Aymen Chalouf, and Francine Krief. Edge

computing based applications in vehicular environments : Comparative
study and main issues. Journal of Computer Science and Technology,
34(4) :869–886, 2019.
187
Bibliographie
[MCK19b] Leo Mendiboure, Mohamed Aymen Chalouf, and Francine Krief. A sdn-
based pub/sub middleware for geographic content dissemination in in-
ternet of vehicles. In 2019 IEEE 90th Vehicular Technology Conference
(VTC2019-Fall), pages 1–6. IEEE, 2019.
[MCK20a] Leo Mendiboure, Mohamed-Aymen Chalouf, and Francine Krief. A sca-

lable blockchain-based approach for authentication and access control in
software defined vehicular networks. In 29th International Conference on
Computer Communication and Networks, ICCCN 2020, pages 1–11, 2020.
[MCK20b] Leo Mendiboure, Mohamed Aymen Chalouf, and Francine Krief. Survey
on blockchain-based applications in internet of vehicles. Computers &
Electrical Engineering, 84 :106646, 2020.
[MdSNP08] Daniel F Macedo, Aldri L dos Santos, José Marcos S Nogueira, and Guy
Pujolle. A knowledge plane for autonomic context-aware wireless mobile
ad hoc networks. In IFIP/IEEE International Conference on Management
of Multimedia Networks and Services, pages 1–13. Springer, 2008.
[MEGBT16] Bouchra Marzak, Kamal El Guemmat, EH Benlahmar, and M Talea. Clus-

tering in vehicular ad-hoc network using artificial neural network. Inter-
national Review on Computers and Software (IRECOS), 11(6) :548–556,
2016.
[MMF+ 19] Bruno José C de A Martins, Diogo MF Mattos, Natalia C Fernandes, Dé-
bora Muchaluat-Saade, Alex Borges Vieira, and Edelberto Franco Silva.
An extensible access control architecture for software defined networks
based on x. 812. In 2019 IEEE Latin-American Conference on Communica-
tions (LATINCOM), pages 1–6. IEEE, 2019.
[MMM+ 16] Trent McConaghy, Rodolphe Marques, Andreas Müller, Dimitri De Jon-
ghe, Troy McConaghy, Greg McMullen, Ryan Henderson, Sylvain Belle-
mare, and Alberto Granzotto. Bigchaindb : a scalable blockchain data-
base. white paper, BigChainDB, 2016.
188
Bibliographie
[MNA+ 18] Nisha Malik, Priyadarsi Nanda, Arushi Arora, Xiangjian He, and Deepak
Puthal. Blockchain based secured identity authentication and expedi-
tious revocation framework for vehicular networks. In 2018 17th IEEE
International Conference On Trust, Security And Privacy In Computing And
Communications/12th IEEE International Conference On Big Data Science
And Engineering (TrustCom/BigDataSE), pages 674–679. IEEE, 2018.
[MRNC+ 17] Albert Mestres, Alberto Rodriguez-Natal, Josep Carner, Pere Barlet-Ros,
Eduard Alarcón, Marc Solé, Victor Muntés-Mulero, David Meyer, Sharon
Barkai, Mike J Hibbett, et al. Knowledge-defined networking. ACM SIG-
COMM Computer Communication Review, 47(3) :2–10, 2017.
[MVC+ 15] Raul Munoz, Ricard Vilalta, Ramon Casellas, Ricardo Martínez, Thomas
Szyrkowiec, Achim Autenrieth, Victor López, and Diego López. Sdn/nfv
orchestration for dynamic deployment of virtual sdn controllers as vnf
for multi-tenant optical networks. In Optical Fiber Communication Confe-
rence, pages W4J–5. Optical Society of America, 2015.
[Nak19] Satoshi Nakamoto. Bitcoin : A peer-to-peer electronic cash system. Tech-

nical report, Manubot, 2019.
[NQATN18] Qassim Nasir, Ilham A Qasse, Manar Abu Talib, and Ali Bou Nassif. Per-
formance analysis of hyperledger fabric platforms. Security and Commu-
nication Networks, 2018, 2018.
[PD+ 18] Reza M Parizi, Ali Dehghantanha, et al. Smart contract programming lan-
guages on blockchains : An empirical evaluation of usability and security.
In International Conference on Blockchain, pages 75–91. Springer, 2018.
[PGAHA+ 16] Jonathan Prados-Garzon, Oscar Adamuz-Hinojosa, Pablo Ameigeiras,

Juan J Ramos-Munoz, Pilar Andres-Maldonado, and Juan M Lopez-Soler.
Handover implementation in a 5g sdn-based mobile network architec-
ture. In 2016 IEEE 27th Annual International Symposium on Personal, In-
door, and Mobile Radio Communications (PIMRC), pages 1–6. IEEE, 2016.
189
Bibliographie
[PGDB17] Otto Julio Ahlert Pinno, Andre Ricardo Abed Gregio, and Luis CE
De Bona. Controlchain : Blockchain as a central enabler for access control
authorizations in the iot. In GLOBECOM 2017-2017 IEEE Global Commu-
nications Conference, pages 1–6. IEEE, 2017.
[PTSD18] Petar Popovski, Kasper Fløe Trillingsgaard, Osvaldo Simeone, and Giu-
seppe Durisi. 5g wireless network slicing for embb, urllc, and mmtc : A
communication-theoretic view. IEEE Access, 6 :55765–55779, 2018.
[RASD19] Gabriel Antonio F Rebello, Igor D Alvarenga, Igor J Sanz, and Otto Car-
los MB Duarte. Bsec-nfvo : A blockchain-based security for network func-
tion virtualization orchestration. In ICC 2019-2019 IEEE International
Conference on Communications (ICC), pages 1–6. IEEE, 2019.
[RASM17] Seyed Hamed Rastegar, Aliazam Abbasfar, and Vahid Shah-Mansouri. On

fair rule caching in software defined radio access networks. IEEE Wireless
Communications Letters, 7(3) :460–463, 2017.
[RCCF19] Malalatiana Randriamasy, Adnane Cabani, Houcine Chafouk, and Guy

Fremont. Formally validated of novel tolling service with the its-g5. IEEE
Access, 7 :41133–41144, 2019.
[ROOA15] Jorge Luis Reyes-Ortiz, Luca Oneto, and Davide Anguita. Big data analy-
tics in the cloud : Spark on hadoop vs mpi/openmp on beowulf. In INNS
Conference on Big Data, volume 8, page 121, 2015.
[RSM+ 13] Theodore S Rappaport, Shu Sun, Rimma Mayzus, Hang Zhao, Yaniv Azar,
Kevin Wang, George N Wong, Jocelyn K Schulz, Mathew Samimi, and
Felix Gutierrez. Millimeter wave mobile communications for 5g cellular :
It will work ! IEEE access, 1 :335–349, 2013.
[RVK+ 12] Sathyanarayanan Rangarajan, Monica Verma, Anand Kannan, Ayush

Sharma, and Ingmar Schoen. V2c : a secure vehicle to cloud framework
for virtualized and on-demand service provisioning. In Proceedings of the
190
Bibliographie
International Conference on Advances in Computing, Communications and

Informatics, pages 148–154, 2012.
[SAA+ 15] Riccardo Scopigno, Alessia Autolitano, Tankut Acarman, Çağdaş Yaman,
and Suat Topsu. The potential benefits of on-board li-fi for the coopera-
tion among vehicles. In 2015 17th International Conference on Transpa-
rent Optical Networks (ICTON), pages 1–6. IEEE, 2015.
[SAA18] Malak Sadik, Nadine Akkari, and Ghadah Aldabbagh. Sdn-based han-
dover scheme for multi-tier lte/femto and d2d networks. Computer Net-
works, 142 :142–153, 2018.
[Sat14] Satyanarayanan. Cloudlet-based edge computing, 2014.
[SBC+ 17] Chen Sun, Jun Bi, Haoxian Chen, Hongxin Hu, Zhilong Zheng, Shuyong
Zhu, and Chenghui Wu. Sdpa : Toward a stateful data plane in software-
defined networking. IEEE/ACM Transactions on Networking, 25(6) :3294–
3308, 2017.
[SBN18] Rakesh Shrestha, Rojeena Bajracharya, and Seung Yeob Nam.

Blockchain-based message dissemination in vanet. In 2018 IEEE 3rd Inter-
national Conference on Computing, Communication and Security (ICCCS),
pages 161–166. IEEE, 2018.
[SCS+ 17] Andrea Suisani, Andrew Clifford, Andrew Stone, Erik Beijnoff, Peter
Rizun, Peter Tschipper, Alexandra Fedorova, Chen Feng, Victoria Le-
mieux, and Stefan Matthews. Measuring maximum sustained transaction
throughput on a global network of bitcoin nodes. Proc. Scaling Bitcoin
(November 2017), 2017.
[SFGL14] Ali Safa Sadiq, Norsheila Binti Fisal, Kayhan Zrar Ghafoor, and Jaime
Lloret. An adaptive handover prediction scheme for seamless mobility
based wireless networks. The Scientific World Journal, 2014, 2014.
[SGSY16] Vincenzo Sciancalepore, Fabio Giust, Konstantinos Samdanis, and Zarrar

Yousaf. A double-tier mec-nfv architecture : Design and optimisation. In
191
Bibliographie
2016 IEEE Conference on standards for communications and networking

(CSCN), pages 1–6. IEEE, 2016.
[SHNS15] Sandra Scott-Hayward, Sriram Natarajan, and Sakir Sezer. A survey of

security in software defined networks. IEEE Communications Surveys &
Tutorials, 18(1) :623–654, 2015.
[SHV+ 15] Alexandru L Stancu, Simona Halunga, Alexandru Vulpe, George Suciu,
Octavian Fratu, and Eduard C Popovici. A comparison between seve-
ral software defined networking controllers. In 2015 12th International
Conference on Telecommunication in Modern Satellite, Cable and Broadcas-
ting Services (TELSIKS), pages 223–226. IEEE, 2015.
[SJC19] Mehrdad Salimitari, Mohsen Joneidi, and Mainak Chatterjee. Ai-enabled

blockchain : An outlier-aware consensus protocol for blockchain-based
iot networks. In 2019 IEEE Global Communications Conference (GLOBE-
COM), pages 1–6. IEEE, 2019.
[SKB+ 13] Yuya Saito, Yoshihisa Kishiyama, Anass Benjebbour, Takehiro Nakamura,
Anxin Li, and Kenichi Higuchi. Non-orthogonal multiple access (noma)
for cellular future radio access. In 2013 IEEE 77th vehicular technology
conference (VTC Spring), pages 1–5. IEEE, 2013.
[SKS14] Sandra Scott-Hayward, Christopher Kane, and Sakir Sezer. Operation-

checkpoint : SDN application control. In 22nd IEEE International Confe-
rence on Network Protocols, ICNP 2014, Raleigh, NC, USA, October 21-24,
2014, pages 618–623. IEEE, 2014.
[SL19] Muhammad Sameer Sheikh and Jun Liang. A comprehensive survey on

vanet security services in traffic management system. Wireless Communi-
cations and Mobile Computing, 2019, 2019.
[SLF11] Kehua Su, Jie Li, and Hongbo Fu. Smart city and the applications. In
2011 international conference on electronics, communications and control
(ICECC), pages 1028–1031. IEEE, 2011.
192
Bibliographie
[SMAC16] KL Kushan Sudheera, Maode Ma, GG Md Nawaz Ali, and Peter Han Joo
Chong. Delay efficient software defined networking based architecture
for vehicular networks. In 2016 IEEE International Conference on Com-
munication Systems (ICCS), pages 1–6. IEEE, 2016.
[SMZS19] Sarah Ali Siddiqui, Adnan Mahmood, Wei Emma Zhang, and Quan Z
Sheng. Poster : A machine learning based hybrid trust management heu-
ristic for vehicular ad hoc networks. In The 25th Annual International
Conference on Mobile Computing and Networking, pages 1–3, 2019.
[SNL18] Ousmane Sadio, Ibrahima Ngom, and Claude Lishou. Sdn architecture
for intelligent vehicular sensors networks. In 2018 UKSim-AMSS 20th
International Conference on Computer Modelling and Simulation (UKSim),
pages 139–144. IEEE, 2018.
[SPMS13] José Santa, Fernando Pereñíguez, Antonio Moragón, and Antonio F Skar-
meta. Vehicle-to-infrastructure messaging proposal based on cam/denm
specifications. In 2013 IFIP Wireless Days (WD), pages 1–7. IEEE, 2013.
[SS14] MK Saggi and RK Sandhu. A survey of vehicular ad hoc network on

attacks and security threats in vanets. In International Conference on
Research and Innovations in Engineering and Technology (ICRIET 2014),
pages 19–20, 2014.
[SSCU16] Victor Sandonis, Ignacio Soto, Maria Calderon, and Manuel Urueña.
Vehicle to internet communications using the etsi its geonetworking
protocol. Transactions on Emerging Telecommunications Technologies,
27(3) :373–391, 2016.
[SSIRR+ 19] José Santa, Ramon Sanchez-Iborra, Pablo Rodriguez-Rey, Luis Bernal-
Escobedo, and Antonio F Skarmeta. Lpwan-based vehicular monitoring
platform with a generic ip network interface. Sensors, 19(2) :264, 2019.
[SSJP17] Pradip Kumar Sharma, Saurabh Singh, Young-Sik Jeong, and Jong Hyuk
Park. Distblocknet : A distributed blockchains-based secure sdn archi-
193
Bibliographie
tecture for iot networks. IEEE Communications Magazine, 55(9) :78–85,

2017.
[SSR16] K Sumathi, V Seethalakshmi, and MA Raja. Analyzing qos based stable

energy aware adhoc routing protocol with different mobility models. Int
J Adv Engg Tech/Vol. VII/Issue II/April-June, 950 :954, 2016.
[SSZ+ 18] Yuxuan Sun, Jinhui Song, Sheng Zhou, Xueying Guo, and Zhisheng Niu.
Task replication for vehicular edge computing : A combinatorial multi-
armed bandit based approach. In 2018 IEEE Global Communications
Conference (GLOBECOM), pages 1–7. IEEE, 2018.
[TBW+ 17] Hoang Duy Trinh, Nicola Bui, Joerg Widmer, Lorenza Giupponi, and
Paolo Dini. Analysis and modeling of mobile traffic using real traces.
In 2017 IEEE 28th Annual International Symposium on Personal, Indoor,
and Mobile Radio Communications (PIMRC), pages 1–6. IEEE, 2017.
[TOAV17] Soufian Toufga, Philippe Owezarski, Slim Abdellatif, and Thierry Ville-
mur. An sdn hybrid architecture for vehicular networks : Application to
intelligent transport system. arXiv preprint arXiv :1712.05307, 2017.
[TS15] Rakesh Taori and Arun Sridharan. Point-to-multipoint in-band mmwave

backhaul for 5g networks. IEEE Communications Magazine, 53(1) :195–
201, 2015.
[TSAEA14] Thouraya Toukabri, Adel Mounir Said, Emad Abd-Elrahman, and Hossam
Afifi. Cellular vehicular networks (cvn) : Prose-based its in advanced 4g
networks. In 2014 IEEE 11th International Conference on Mobile Ad Hoc
and Sensor Systems, pages 527–528. IEEE, 2014.
[TV16] PV Tijare and D Vasudevan. The northbound apis of software defined

networks. International journal of engineering sciences and research tech-
nology, 2016.
194
Bibliographie
[UP13] S Umamaheswari and RM Priya. An efficient healthcare monitoring sys-

tem in vehicular ad hoc networks. International Journal of Computer
Applications, 78(7), 2013.
[Wan12] Fei-Yue Wang. A big-data perspective on ai : Newton, merton, and analy-

tics intelligence. IEEE Intelligent Systems, 27(5) :2–4, 2012.
[Weg17] Fred Wegman. The future of road safety : A worldwide perspective. IATSS
research, 40(2) :66–71, 2017.
[WHW+ 19] Xiaofei Wang, Yiwen Han, Chenyang Wang, Qiyang Zhao, Xu Chen, and
Min Chen. In-edge ai : Intelligentizing mobile edge computing, caching
and communication by federated learning. IEEE Network, 33(5) :156–
165, 2019.
[WLC+ 17] Mengmeng Wang, Jianwei Liu, Jie Chen, Xiao Liu, and Jian Mao. Perm-
guard : Authenticating the validity of flow rules in software defined net-
working. Journal of Signal Processing Systems, 86(2-3) :157–173, 2017.
[WLW+ 16] Luhan Wang, Zhaoming Lu, Xiangming Wen, Raymond Knopp, and Ro-
hit Gupta. Joint optimization of service function chaining and resource
allocation in network function virtualization. IEEE Access, 4 :8084–8094,
2016.
[WMG17] Xuyu Wang, Shiwen Mao, and Michelle X Gong. An overview of 3gpp
cellular vehicle-to-everything standards. GetMobile : Mobile Computing
and Communications, 21(3) :19–25, 2017.
[WPZL16] Rui Wang, Xi Peng, Jun Zhang, and Khaled B Letaief. Mobility-aware ca-
ching for content-centric wireless networks : Modeling and methodology.
IEEE Communications Magazine, 54(8) :77–83, 2016.
[WSGB14] Md Whaiduzzaman, Mehdi Sookhak, Abdullah Gani, and Rajkumar

Buyya. A survey on vehicular cloud computing. Journal of Network and
Computer applications, 40 :325–344, 2014.
195
Bibliographie
[WYC+ 16] Xitao Wen, Bo Yang, Yan Chen, Li Erran Li, Kai Bu, Peng Zheng, Yang
Yang, and Chengchen Hu. Ruletris : Minimizing rule update latency for
tcam-based sdn switches. In 2016 IEEE 36th International Conference on
Distributed Computing Systems (ICDCS), pages 179–188. IEEE, 2016.
[WYQM18] Kai Wang, Hao Yin, Wei Quan, and Geyong Min. Enabling collaborative
edge computing for software defined vehicular networks. IEEE Network,
32(5) :112–117, 2018.
[XDYW19] Lixia Xie, Ying Ding, Hongyu Yang, and Xinmu Wang. Blockchain-based
secure and trustworthy internet of things in sdn-enabled 5g-vanets. IEEE
Access, 7 :56656–56666, 2019.
[XWL15] Shunyi Xu, Chuan Wu, and Zongpeng Li. Software defined mobile mul-
ticast. In 2015 IEEE 12th International Conference on Mobile Ad Hoc and
Sensor Systems, pages 208–216. IEEE, 2015.
[YAA+ 17] Ibrar Yaqoob, Iftikhar Ahmad, Ejaz Ahmed, Abdullah Gani, Muhammad
Imran, and Nadra Guizani. Overcoming the key challenges to establishing
vehicular communication : Is sdn the answer ? IEEE Communications Ma-
gazine, 55(7) :128–134, 2017.
[YBSS17] Faqir Zarrar Yousaf, Michael Bredel, Sibylle Schaller, and Fabian Schnei-
der. Nfv and sdn—key technology enablers for 5g networks. IEEE Journal
on Selected Areas in Communications, 35(11) :2468–2478, 2017.
[YCM+ 19] Yingying Yao, Xiaolin Chang, Jelena Mišić, Vojislav B Mišić, and Lin
Li. Bla : blockchain-assisted lightweight anonymous authentication
for distributed vehicular fog services. IEEE Internet of Things Journal,
6(2) :3775–3784, 2019.
[YCT+ 19] Yao-Tsung Yang, Li-Der Chou, Chia-Wei Tseng, Fan-Hsun Tseng, and
Chien-Chang Liu. Blockchain-based traffic event validation and trust ve-
rification for vanets. IEEE Access, 7 :30868–30877, 2019.
196
Bibliographie
[YSW+ 18] Alexander Yakubov, Wazen Shbair, Anders Wallbom, David Sanda,
et al. A blockchain-based pki management framework. In The First
IEEE/IFIP International Workshop on Managing and Managed by Block-
chain (Man2Block) colocated with IEEE/IFIP NOMS 2018, Tapei, Tawain
23-27 April 2018, 2018.
[YWP+ 16] Jinke Yu, Ying Wang, Keke Pei, Shujuan Zhang, and Jiacong Li. A load ba-
lancing mechanism for multiple sdn controllers based on load informing
strategy. In 2016 18th Asia-Pacific Network Operations and Management
Symposium (APNOMS), pages 1–4. IEEE, 2016.
[YYS+ 19] Ruizhe Yang, F Richard Yu, Pengbo Si, Zhaoxin Yang, and Yanhua Zhang.
Integrated blockchain and edge computing systems : A survey, some re-
search issues and challenges. IEEE Communications Surveys & Tutorials,
21(2) :1508–1532, 2019.
[ZADZ+ 19] Liang Zhao, Ahmed Al-Dubai, Albert Y Zomaya, Geyong Min, Ammar
Hawbani, and Jiajia Li. Routing schemes in software-defined vehicular
networks : Design, open issues, and challenges. IEEE Intelligent Transpor-
tation Systems Magazine, 2019.
[ZCC+ 16] Ming Zhu, Jiannong Cao, Zhiping Cai, Zongjian He, and Ming Xu. Provi-
ding flexible services for heterogeneous vehicles : an nfv-based approach.
IEEE network, 30(3) :64–71, 2016.
[ZD18] Hongtao Zhang and Lingcheng Dai. Mobility prediction : A survey on

state-of-the-art schemes and future applications. IEEE Access, 7 :802–822,
2018.
[ZFLJ15] Huikang Zhu, Hongbo Fan, Xuan Luo, and Yaohui Jin. Intelligent timeout
master : Dynamic timeout for sdn-based data centers. In 2015 IFIP/IEEE
International Symposium on Integrated Network Management (IM), pages
734–737. IEEE, 2015.
197
Bibliographie
[ZFY+ 18] Zainab Zaidi, Vasilis Friderikos, Zarrar Yousaf, Simon Fletcher, Mischa
Dohler, and Hamid Aghvami. Will sdn be part of 5g ? IEEE Communica-
tions Surveys & Tutorials, 20(4) :3220–3258, 2018.
[ZQML18] Yi Zeng, Meikang Qiu, Zhong Ming, and Meiqin Liu. Senior2local : A
machine learning based intrusion detection method for vanets. In In-
ternational Conference on Smart Computing and Communication, pages
417–426. Springer, 2018.
[ZWZ18] Xiao Zhang, Haijun Wang, and Haitao Zhao. An sdn framework for uav
backbone network towards knowledge centric networking. In IEEE IN-
FOCOM 2018-IEEE Conference on Computer Communications Workshops
(INFOCOM WKSHPS), pages 456–461. IEEE, 2018.
[ZWZ19] Ning Zhao, Hao Wu, and Xiaonan Zhao. Consortium blockchain-based
secure software defined vehicular network. Mobile Networks and Applica-
tions, pages 1–14, 2019.
[ZYCW20] Jingjing Zhang, Lin Yang, Weipeng Cao, and Qiang Wang. Formal ana-
lysis of 5g eap-tls authentication protocol using proverif. IEEE Access,
8 :23674–23688, 2020.
[ZYY19] Dajun Zhang, F Richard Yu, and Ruizhe Yang. Blockchain-based distri-
buted software-defined vehicular networks : A dueling deep Q -learning
approach. IEEE Transactions on Cognitive Communications and Networ-
king, 5(4) :1086–1100, 2019.
[ZZC17] Wenyu Zhang, Zhenjiang Zhang, and Han-Chieh Chao. Cooperative fog
computing for dealing with big data in the internet of vehicles : Architec-
ture and hierarchical resource management. IEEE Communications Ma-
gazine, 55(12) :60–67, 2017.
198
199
Annexes
A. Architecture de référence ETSI ISG NFV
F IGURE 7.1 – Architecture ETSI ISG NFV 1
L’architecture standardisée pour la technologie NFV, telle que proposée par l’ETSI
Industry Specification Group NFV 2 , est composée de trois éléments spécifiques (cf. Figure
7.1) :
— l’infrastructure NFV (NFVI, NFV Infrastructure) : qui correspond à la virtualisa-

tion de l’infrastructure matérielle. Ainsi, NFVI permet de mettre les ressources
1. Source : ETSI https://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.01.01_60/gs_
NFV002v010101p.pdf
2. https://docbox.etsi.org/ISG/NFV/Open/Other/ReleaseDocumentation/NFV(20)000015_
NFV_Release_2_Description_v1_10_0.pdf
200
Annexes
matérielles (serveurs X86, cartes électroniques, etc.) à disposition des fonctions

réseau virtualisées en introduisant une couche de virtualisation ;
— les fonctions réseau virtualisées (VNF, Virtualised Network Functions) : qui cor-
respondent aux fonctions virtualisées pouvant être déployées dans l’infrastructure
NFV : pare-feux, routeurs, etc. Le fonctionnement de ces fonctions réseau repose
sur l’idée d’une encapsulation au sein de conteneurs ou de machines virtuelles.
Ainsi, chaque fonction évolue dans un environnement qui lui est propre, isolée
des autres fonctions virtuelles déployées ;
— la gestion et l’orchestration NFV (NFV MANO, NFV Management and Orchestra-
tion) : qui permet de gérer le déploiement des fonctions réseau virtualisées. Ainsi,
ce plan permet une mise en relation entre les VNF déployées sur l’infrastructure
NFV et les ressources matérielles existantes. Il assure également une gestion du
cycle de vie des services.
201
Annexes
B. Comparaison des principales technologies de com-

munication véhiculaires
Caractéristique ITS G5 LTE V2X 5G NR

Synchronisation Asynchrone Synchrone (mode 3) Asynchrone
Taille du 10/20MHz
10/20MHz 10/20MHz
canal 40-100MHz
Multiplexage TMD TDM/FDM TDM/FDM
Codage
Conventionnel Turbo LDPC
canal
Retransmission
Non Oui Oui
HARQ
Forme d’onde OFDM SD-FDM OFDMA
MIMO Non 2 antennes RX/TX 8 antennes RX/TX
Modulation 64 QAM 64 QAM 256 QAM
Tableau 7.1 – Comparaison technique des différentes technologies d’accès
Ces données proviennent du rapport du groupe de travail : Technologies de commu-

nication pour les STI coopératifs 3 .
3. https://www.ecologique-solidaire.gouv.fr/sites/default/files/Rapport%20GT%
20technologies%20STI-vfin.pdf
202
Annexes
C. Comparaison des différentes approches d’Edge Com-

puting
XX Tech.
XX
MEC Cloudlet FC
Caract. XXXX
Carnegie Mellong
Fondateur ETSI Cisco
University
Open Edge OpenFog
Organisme de ETSI ISG
Computing Initiative Consortium
soutien (Opérateurs réseau)
(Fournisseurs de services) (Constructeurs)
Cloud Cloud Cloud
Architecture Noeud de calcul Noeud de calcul 1 à N Noeud(s)
Utilisateur terminal Utilisateur terminal Utilisateur terminal
Noeud RAN Routeur, Passerelle,
Type de noeuds Micro Cloud Mobile
(eNB, RNC, etc.) Wifi AP, etc.
Réseaux cellulaires,
Technologie de
Réseaux cellulaires Wifi Wifi, Bluetooth,
communication
Li-Fi, etc.
Coopération inter noeuds Non Communiqué Non Communiqué Oui
Communications non basées
Non Non Oui
sur IP
Plateforme logicielle NFV OpenStack, etc. Couche d’abstraction Fog
Capacité de stockage Élevée Élevée Faible
Capacité de
Élevée Élevée Faible
calcul
Tolérance aux fautes Faible Faible Élevée
Coût de
Élevé Moyen Faible
déploiement
Utilisateurs
Clients des opérateurs Tout le monde Tout le monde
potentiels
Information de position
(Précise) Information de position Information de position
Objets environnant (Imprécise) (Imprécise)
Adaptation au
(Faible) Objets environnant Objets environnant
contexte
Facteurs environnementaux (Élevé) (Élevé)
Statut de l’objet Facteurs environnementaux Facteurs environnementaux
(Informations réseau)
Couverture Élevée Moyenne Variable
Un ou
Nombre de sauts Un Un
plusieurs
Proximité de l’utilisateur Moyenne Haute Variable
Flexibilité Faible Moyenne Haute
Interaction en
Partielle Partielle Partielle
temps-réel
Tableau 7.2 – Comparaison des différentes approches d’Edge Computing
Le tableau 7.2 offre une rapide comparaison des principales principales approches
d’Edge Computing (Cloudlet, MEC, Fog Computing) et met en évidence leurs diffé-
rences : adaptation au contexte, coût de déploiement, capacité de calcul, technologie
d’accès, etc.
203
Annexes
Une comparaison plus poussée, présentant les applications et les limites de chacune
de ces technologies dans l’environnement véhiculaire, est accessible dans une étude que
nous avons menée [MCK19a].
204
Annexes
D. Architecture ETSI de référence pour la technologie

MEC
Comme cela est indiqué dans la section 3.3.3.1, différentes implémentations ont
déjà été proposées pour la technologie EC. Par conséquent, des architectures spécifiques
ont été proposées pour chacune de ces implémentations. Néanmoins, ces différentes
approches, ayant un même objectif, présentent des caractéristiques similaires.
F IGURE 7.2 – Architecture ETSI GS MEC
Aussi, dans cette section, nous nous proposons de présenter les principaux com-
posants de l’architecture Multi-Access Edge Computing proposée par l’ETSI 4 (cf. Figure
7.2) :
— les applications MEC : il s’agit de machines virtuelles déployées au dessus de

la couche de virtualisation offerte par l’approche MEC. Ces applications MEC
4. https://www.etsi.org/deliver/etsi_gs/MEC/001_099/003/02.01.01_60/gs_
MEC003v020101p.pdf
205
Annexes
peuvent correspondre à tout type d’applications dont le déploiement pourrait être

considéré dans un environnement Cloud (gestion du trafic, divertissement, gestion
du véhicule, etc.) ;
— la plateforme MEC : cette entité fournit l’ensemble des fonctionnalités nécessaires
au déploiement et au fonctionnement des applications MEC dans un environne-
ment de virtualisation MEC. Ainsi, la plateforme MEC permet la mise en relation
entre applications MEC et services MEC (géocalisation, ressources radio, bande
passante, stockage de données, horodatage, etc.) afin de garantir le bon fonction-
nement de ces services ;
— l’hôte MEC : il s’agit d’une entité contenant la plateforme MEC et une couche de
virtualisation devant permettre d’offrir les capacités de stockage, de calcul et de
communication aux applications MEC. On peut noter que cette couche de virtua-
lisation peut s’appuyer sur une technologie qui pourrait également présenter de
nombreux bénéfices pour les réseaux de communication véhiculaires [SGSY16] :
NFV (3.3.2.2) ;
— l’orchestrateur MEC : cette entité est en charge de la gestion du système dans sa
globalité. Ainsi, l’orchestrateur MEC doit disposer d’une vision de l’ensemble des
hôtes MEC et de l’état de ces hôtes : topologie, ressources disponibles, applica-
tions MEC disponibles, etc. L’orchestrateur gère notamment le positionnement et
le déplacement des applications MEC, en fonction de leurs besoins (latence, bande
passante, etc.) et des ressources disponibles au niveau de chaque hôte MEC ;
— le gestionnaire de la plateforme MEC : cette entité est en charge de la gestion
du cycle de vie des applications MEC déployées au sein d’un hôte MEC. De plus,
ce gestionnaire permet à l’orchestrateur MEC de disposer d’une vision globale de
l’état du réseau grâce à une remontée d’informations concernant ces applications.
Enfin, le gestionnaire de la plateforme est en charge de l’application des règles
définies pour chacune des applications MEC : autorisations, configuration DNS,
etc.
Note : cette architecture provient du rapport (V2.1.1) produit par le groupe de spé-
cification de l’ETSI travaillant sur la définition d’un framework et d’une architecture
normalisée pour la technologie MEC 5
5. https://www.etsi.org/deliver/etsi_gs/MEC/001_099/003/02.01.01_60/gs_
206
Annexes
E. Cas d’utilisation de GeoNet : Dissémination géogra-

phique des données assistée par l’infrastructure
Note : l’image et l’exemple présentés dans cette annexe sont issus du rapport final du
projet sur le protocole GeoNet 6 .
L’exemple présenté dans la Figure 7.3 correspond à un cas d’utilisation du protocole
GeoNet pour la distribution géographique de données.
F IGURE 7.3 – Exemple de dissémination géographique des données
Le véhicule A, ayant détecté la présence d’un obstacle sur la route (plaque de ver-
glas), doit transmettre cette information à l’ensemble des véhicules pour lesquels elle
MEC003v020101p.pdf
6. D1.2 Final GeoNet Architecture Design https://cordis.europa.eu/docs/projects/cnect/9/
216269/080/deliverables/001-GeoNetD12v12.pdf
207
Annexes
pourrait être pertinente (B, C, D, E, F). Pour que cette transmission soit possible, le
fonctionnement adopté est le suivant :
1. en utilisant des communications directes V2V (GeoBroadcast), A transmet cette in-
formation aux véhicules situés directement à proximité (B) qui, eux même, trans-
mettent cette information aux véhicules auxquels ils sont connectés (C) ;
2. en utilisant des communications V2I/V2N (GeoUnicast), A envoie également cette
notification à l’équipement de bord de route le plus proche (RSU 1) ;
3. l’équipement de bord de route (RSU 1) transmet cette information (IPv6 unicast)
au centre de contrôle des dangers de la circulation (Control Centre) ;
4. le centre de contrôle des dangers de la circulation détermine la zone géographique
dans laquelle cette information doit être transmise ;
5. le centre de contrôle des dangers de la circulation transmet cette information
(IpV6 Multicast) aux équipements de bord de route identifiés comme étant situés
dans cette zone géographique (RSU 2) ;
6. chaque équipement de bord de route (RSU 2) envoie cette information (Geo-
Broadcast) aux véhicules qui lui sont connectés (D, E, F).
Il est à noter que des RSU sont considérés dans cet exemple mais que d’autres équi-
pements de bord de route, notamment des stations de base, pourraient être utilisés pour
cette diffusion.
208
Annexes
F. Procédure de handover dans les réseaux 5G définis

logiciellement
Dans les réseaux 5G, la définition de mécanismes de handover efficaces est essen-
tielle. En effet, le fonctionnement des réseaux 5G s’appuie sur des cellules de faible
rayon et de faible capacité (small cells) [TBW+ 17]. Par conséquent, une station de base
pourrait rapidement se retrouver surchargée. Ceci entraînerait, inévitablement, une dé-
gradation des performances (latence, bande passante, perte de paquets) et de la qualité
d’expérience de l’utilisateur. De plus, les équipements terminaux (véhicules) peuvent
rapidement se déplacer d’une cellule à une autre.
Par conséquent, une répartition performante de la charge entre les différentes sta-
tions de base, prenant en compte la mobilité des équipements terminaux, est essentielle.
De nombreux travaux à l’image de [BCC17, PGAHA+ 16, SAA18] ont proposé la défini-
tion et l’implémentation de mécanismes de handover dans un environnement 5G défini
logiciellement.
Le scénario présenté dans [BCC17] est le suivant. Le handover d’un équipement
terminal doit être réalisé entre une station de base d’origine (oNB) et une station de
base de destination (dNB). Ces deux stations de base sont connectées à un routeur
régional (RR) qui permet aux équipements terminaux d’accéder aux réseau Internet. Ce
routeur régional a notamment pour rôle de permettre la redirection du trafic destiné
aux équipements terminaux (DL). L’ensemble de ces équipements (stations de base,
routeurs) sont considérés comme étant des équipements SDN programmables.
La procédure adoptée pour gérer le handover avec SDN se décompose en trois
phases :
— la phase de préparation du handover : celle-ci reste à la charge des stations

de base et de l’UE. oNB détectant que le signal vers l’UE devient faible (ou/et
détectant un niveau de charge trop élevé) envoie une demande de handover à
dNB. dNB ayant des ressources suffisantes valide le handover et l’indique à oNB.
L’UE est informée du handover devant être réalisé ;
— la phase d’interruption : l’UE est transférée de oNB vers dNB. Cette UE, à cet
instant, n’est plus en mesure d’uploader des données. oNB transfère les données
destinées à l’UE à dNB (DL) puis indique à RR que l’UE n’est plus joignable ;
209
Annexes
F IGURE 7.4 – Représentation du fonctionnement du handover pour les réseaux 5G défi-

nis logiciellement
— la phase de complétion : dNB indique au contrôleur SDN qu’il ne sait pas com-
ment distribuer les données destinées à l’UE (Packet In). Le contrôleur SDN de-
mande aux applications (AMF, SMF) quel comportement doit être adopté. Ce
même contrôleur traduit les demandes des applications en règles de flux et les
déploie au niveau de RR et de dNB. oNB est informée. Le handover est terminé.
L’ensemble de cette procédure est présentée en figure 7.4.
210
Annexes
G. Fonctionnement du protocole OpenFlow

Le protocole OpenFlow correspond à une définition de l’interface sud de l’architec-
ture SDN (cf. Section 3.3.1.2). Il s’agit, actuellement, du protocole le plus utilisé pour
cette interface. Au travers de la définition d’un ensemble de messages standardisés (Pa-
cketIn, PacketOut, FlowMod, etc.), ce protocole permet de définir les échanges entre
contrôleurs SDN et équipements réseau.
Le fonctionnement des switches OpenFlow repose sur une idée centrale : la défi-
nition de tables de flux dynamiques. Ces tables de flux contiennent un ensemble de
règles de flux (règles de routage) ajoutées dynamiquement par le contrôleur SDN. Elles
permettent aux switches OpenFlow d’assurer la transmission des paquets.
Ces règles de flux fonctionnent sur un principe simple dit de match-action. Chaque
règle de flux correspond à un ensemble de critères (match) : ingress port, ether type,
Eth Dest, Eth Source, IP Protocol, IP Dest, L4 Protocol Source, etc.
Ainsi, lorsqu’un switch OpenFlow reçoit un nouveau paquet, il va extraire de ce pa-
quet ses principales caractéristiques (IP, port, etc.) et parcourir sa table des flux pour
vérifier si une règle correspond bien à ces caractéristiques (cf. Figure 7.5). Si c’est bien
le cas (hit), le switch OpenFlow va transmettre ce paquet en fonction de l’action définie
(egress port). Si ce n’est pas le cas, le switch envoie une requête de type PacketIn au
contrôleur SDN pour savoir comment il doit gérer ce paquet qui ne correspond à au-
cune règle de flux. En réponse, le contrôleur renverra un message PacketOut indiquant
au switch comment gérer ce paquet. Le contrôleur SDN peut également envoyer un
message FlowMod qui vise à ajouter une nouvelle règle à la table des flux du switch.
Ainsi, la prochaine fois que ce switch recevra un paquet de ce type, il sera en mesure de
le transmettre sans intervention du contrôleur.
Il est à noter que les règles de flux déployées au niveau des switches OpenFlow
sont caractérisées par un mécanisme de match-action, mais également par une durée
de vie. Lorsque cette durée de vie est écoulée, les règles de flux sont retirées de la
table des flux. Cette durée de vie correspond à deux variables distinctes : l’Idle Timeout
et l’Hard Timemout. L’Hard Timeout correspond à la durée maximale durant laquelle
une règle de flux restera déployée dans la table de flux d’un switch OpenFlow. L’Idle
Timeout correspond à la durée maximale pouvant s’écouler entre la réception de deux
paquets correspondant à un même flux. Le fonctionnement de l’Idle Timeout se base sur
211
Annexes
les statistiques associées à chaque règle de flux : nombre de bits, nombre de paquets,
instant du dernier paquet, etc.
Enfin, il est à noter que le mécanisme présenté dans cette section permet d’expliquer
la différence entre une approche réactive et une approche pro-active du contrôleur SDN.
Dans le cas d’une approche pro-active le contrôleur SDN cherchera à déployer à l’avance
des règles de flux permettant de gérer l’ensemble des paquets pouvant être reçus par
le switch OpenFlow. Dans le cas d’une approche réactive, le contrôleur SDN attendra
que le switch OpenFlow lui transmette les paquets, qu’il ne sait comment gérer, pour
déployer de nouvelles règles de flux.
F IGURE 7.5 – Procédure des gestion des paquets
212
Annexes
H. SDN : Plan de données avec états

L’idée de définir un Stateful data plane pour les réseaux SDN a été introduite dans
de nombreux papiers [SBC+ 17, CSP+ 17, CPSC15, CRDP19]. Elle a notamment été ap-
pliquée à la définition de chemins de communication secondaires en cas de rupture de
lien [CSP+ 17], au balancement de charge entre différents serveurs [SBC+ 17, CPSC15]
ou à la gestion de pare-feux [CRDP19].
F IGURE 7.6 – Plan de données avec états
Comme cela est montré dans la figure 7.6, cette définition d’un plan de données avec
états consiste à intégrer un nouvel élément aux switches OpenFlow (cf. Annexe G .) :
une table d’états. Cette table d’états est associée à la table de flux dans le processus de
sélection d’une action (port de destination par exemple).
Lorsque le switch OpenFlow reçoit un nouveau paquet, il commence toujours par en
extraire les principales clés : ingress port, ether type, Eth Dest, etc. Ensuite, il regarde
à quel état sont actuellement associées ces clés. L’état correspond à une valeur numé-
rique : 1,2, etc. Cet état se rajoute, ensuite, à la liste de clés caractérisant ce paquet.
Ainsi, lorsque le switch OpenFlow parcourt la table des flux pour voir à quelle règle cor-
respond ce paquet, il prend en compte les clés extraites et l’état déterminé (cf. Figure
7.7).
Ceci permet d’assurer une plus grande flexibilité. En effet, un paquet n’est plus ca-
ractérisé par une seul comportement (une seul port de sortie) mais plusieurs comporte-
ments (plusieurs ports de sorties). Chaque comportement correspond à un état. La tran-
sition entre états peut se réaliser en fonction de différents paramètres. Tout d’abord,
tout comme pour les règles de flux, la durée de vie de cet état (Hard, Idle). Ensuite,
213
Annexes
F IGURE 7.7 – Tables utilisées par le plan de données avec état
contrairement aux règles de flux, ces transitions peuvent être réalisées en fonction de
données remontées par les switches eux-mêmes. Ainsi, comme cela est présenté dans
[CSP+ 17], lorsqu’un switch détecte une rupture de lien, il est en capacité d’informer
l’ensemble des switches via un simple tag du paquet de retour (cf. Figure 7.7). Les
switches disposant de plusieurs états pour ce paquet sont alors en capacité de basculer
d’une règle de flux vers une autre. Ceci garantit donc une redirection des paquets sans
intervention du contrôleur SDN.
Cette approche permet de réduire le temps de latence lié à la gestion des ruptures de
lien ou à l’équilibrage de charge [SBC+ 17, CSP+ 17, CPSC15]. Elle permet, également,
de réduire la charge associée au canal de contrôle. Cette approche pourrait donc s’avérer
intéressante appliquée dans un environnement mobile nécessitant une gestion efficace
de la mobilité.
Il est à noter que les implémentations proposées, à l’image d’OpenState 7 , sont com-
patibles avec le protocole OpenFlow. Elles pourraient donc être intégrées aux solutions
7. https://github.com/OpenState-SDN
214
Annexes
existantes sans nécessiter une évolution des protocoles de communication.
215
Annexes
I. Environnement de simulation considéré

La figure 7.8 présente l’environnement de simulation considéré pour l’évaluation de
la contribution introduite dans le chapitre 4. Les caractéristiques de cet environnement
sont les suivantes :
— des stations de base d’un faible rayon (représentées par des cercles de couleur)
sont uniformément réparties dans un environnement de 600m par 600m ;
— deux zones de distribution géographiques sont considérées : une rouge et une
verte ;
— les stations de base représentées par un cercle rouge/vert sont liées à une seule
zone géographique : la zone géographique rouge/verte ;
— la station de base blanche correspond à une station nécessaire pour la zone rouge
et optionnelle pour la zone verte ;
— la station de base noire correspond à une station nécessaire pour la zone verte et
optionnelle pour la zone rouge.
F IGURE 7.8 – Environnement de simulation considéré
Ainsi, avec notre approche, lorsqu’un véhicule est situé à l’intérieur d’une zone géo-
graphique donnée (zone rouge/zone verte) :
216
Annexes
— les données sont transmises à l’ensemble des stations nécessaires situées à l’inté-
rieur de cette zone géographique (zone verte : BS vertes + BS noire/zone rouge :
BS rouges + BS blanche) ;
— si les ressources sont suffisantes, les données sont également transmises à la sta-
tion de base optionnelle située à l’intérieur de cette zone géographique (zone
verte : BS blanche/zone rouge : BS noire).
Note : Plus de détails concernant les paramètres de simulation considérés sont pré-
sentés dans le tableau 4.2.
217
Annexes
J. Définition d’un plan de connaissance global

Comme nous l’avons indiqué dans le chapitre 3, il pourrait être pertinent d’ajouter
un plan de connaissance à l’architecture de référence C-ITS (c. section 3.5). En effet,
celui-ci pourrait permettre d’améliorer les performances de l’architecture C-ITS dans sa
globalité : plan de contrôle et données, plan de gestion, plan de sécurité et de respect
de la vie privée (cf. Section 3.5.4.1).
Dans les chapitres 4 et 5, nous avons mis en avant les bénéfices que pourrait présen-
ter ce plan de connaissance pour la distribution géographique de données (cf. Section
4.7.1) et la sécurisation des communications (cf. Section 5.7.1). Le tableau 7.3 propose
un rappel des applications du plan de connaissance introduites dans ces sections et des
sources de données nécessaires au fonctionnement de ces applications.
Applications du plan de
Contexte Sources nécessaires
connaissance envisagées
Distribution Véhicules, Stations de Base Mobilité des véhicules
géographique Équipements réseau Niveau de charge des stations de base
de données Contrôleurs SDN Distribution fiable des données
(cf. Chapitre 4) Applications SDN Amélioration du plan de contrôle
Gestion des attaques DoS
Véhicules, Stations de Base
Sécurisation des Estimation du nombre de sous réseaux
Équipements réseau
communication Établissement de confiance
Contrôleurs SDN
(cf. Chapitre 5) Amélioration des performances
Applications SDN, Noeuds Blockchain
du réseau Blockchain
Tableau 7.3 – Applications du plan de connaissance aux propositions introduites dans

les chapitres 4 et 5
Comme nous pouvons le constater, l’utilisation du plan de connaissance pour la sé-

curisation et la distribution de données nécessite des données provenant de mêmes
sources : véhicules, stations de base, etc. Aussi, la définition d’un plan de connaissance
global permettrait de pré-traiter ces données de manière unique. Ceci permettrait donc
d’éviter la duplication de différentes tâches : extraction de données pertinentes, élimi-
nation de doublons, croisement de données, etc.
On peut, également, constater que certains applications du plan de connaissance
sont communes à ces deux contextes. Par exemple, l’analyse du comportement des équi-
pements terminaux est nécessaire, tant pour la sécurisation des interfaces SD-IoV (plan
de contrôle) que pour le contrôle d’admission des véhicules émetteurs (plan de don-
nées). De même, l’analyse du niveau de charge des stations de base pourrait s’avérer
218
Annexes
utile, tant pour la gestion des sous-réseaux Blockchain (plan de gestion) que pour la
distribution des données géographiques (plan de données). Aussi, certaines prises de
décision, et par conséquent certains processus d’analyse des données (Big Data, intelli-
gence artificielle), sont communs à ces applications. La définition d’un plan de connais-
sance unique permettrait d’éviter la duplication de ces tâches longues et coûteuses en
ressources de calcul.
Ainsi, le croisement des sections 5.7.1 et 4.7.1 démontre l’intérêt de la définition glo-
bale d’un plan de connaissance. Celui-ci garantirait une gestion efficace des données,
simplifiant la remontée de données, évitant la duplication de tâches de pré-traitement
et offrant des services communs aux différents plans de l’architecture C-ITS. De plus,
les services propres à chacun des plans (contrôle, gestion, sécurité), tels que la ges-
tion des attaques DoS ou de la gestion de contrôleurs SDN, pourraient être ajoutés à
ce plan. Ainsi, il représenterait un élément central de l’architecture C-ITS, optimisant
globalement son fonctionnement.
219
Annexes
220

Mendiboure Leo 2020

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Mendiboure Leo 2020

Transféré par

Droits d'auteur :

Formats disponibles

THÈSE PRÉSENTÉE

POUR OBTENIR LE GRADE DE

ÉCOLE DOCTORALE DE MATHÉMATIQUES ET INFORMATIQUE (EDMI)

Par Léo MENDIBOURE

Distribution géographique de données dans

M. PUJOLLE, Guy Professeur émérite, Sorbonne Université Président

Résumé Le déploiement de réseaux de communication véhiculaires apparaît au-

Abstract Nowadays, the deployment of vehicular communication networks appears

Keywords Internet of Vehicles, Geographical data dissemination, Security, SDN,

LaBRI (Laboratoire Bordelais de Recherche en Informatique) UMR 5800 - 351 Cours

Ces travaux sont le résultat de l’investissement de plusieurs personnes. Aussi, je tiens à

Table des matières vii

Table des figures xiii

Liste des tableaux xv

Liste des publications xx

2 Vers l’Internet des Véhicules 7

2.3.2.1 Des applications nombreuses et variées . . . . . . . . . 14

3 Une nouvelle architecture de communication pour l’Internet des Véhicules 33

4 Une approche logicielle performante pour la distribution géographique des

4.6.6 Politique de pré-déploiement des règles de flux . . . . . . . . . . 113

5 Une sécurisation des réseaux SD-IoV s’appuyant sur la Blockchain 121

5.5.5 Impact du contrôle d’accès . . . . . . . . . . . . . . . . . . . . . . 155

6 Conclusion et perspectives 168

2.1 Principaux types de communication V2X . . . . . . . . . . . . . . . . . . 12

3.1 Architecture de communication SDN : Application aux réseaux

4.1 Représentation des réseaux 5G définis logiciellement . . . . . . . . . . . 87

5.1 Architecture Blockchain proposée . . . . . . . . . . . . . . . . . . . . . . 136

7.1 Architecture ETSI ISG NFV 3 . . . . . . . . . . . . . . . . . . . . . . . . . 200

7.4 Représentation du fonctionnement du handover pour les réseaux 5G dé-

2.1 Principales applications des réseaux véhiculaires . . . . . . . . . . . . . . 15

3.1 Comparaison des différentes évolutions architecturales proposées . . . . 58

5.1 Comparaison des approches utilisant la Blockchain pour la sécurisation

7.1 Comparaison technique des différentes technologies d’accès . . . . . . . 202

Leo Mendiboure, Mohamed-Aymen Chalouf, et Francine Krief. "Towards new in-

Leo Mendiboure, Mohamed-Aymen Chalouf, et Francine Krief. "Gestion dyna-

Leo Mendiboure, Mohamed-Aymen Chalouf, and Francine Krief. "Survey on

Leo Mendiboure, Mohamed-Aymen Chalouf, and Francine Krief. "Load-aware and

Leo Mendiboure, Mohamed Aymen Chalouf, and Francine Krief. "Towards a 5G

1.1 Contexte et Motivations

— une distribution géographique des données coûteuse : l’infrastructure cellu-

— une sécurisation insuffisante des communications : la sécurisation des commu-

— la définition d’une nouvelle architecture de communication IoV : comme nous

— la définition et l’implémentation d’une approche logicielle pour la distribu-

— la définition et l’implémentation d’une approche basée sur la Blockchain pour

1.4 Organisation de la thèse

suite, nous mettons en avant le principal moteur des réseaux de communications

— Chapitre 3 "Une nouvelle architecture de communication pour l’Internet des

— Chapitre 4 "Une approche logicielle performante pour la distribution géogra-

— Chapitre 5 "Une sécurisation des réseaux SD-IoV s’appuyant sur la Block-

2.2 Présentation générale des réseaux véhiculaires

2.2.1 Les caractéristiques des réseaux véhiculaires

— une topologie réseau hautement dynamique : de part le déplacement à grande

2.2.2 Des composants principaux

— l’unité embarquée (OBU, On Board Unit) : embarqué à l’intérieur des véhicules,

2.2.3 De nombreux types de communication

— Véhicule-à-Véhicule (V2V, Vehicle-to-Vehicle) : il s’agit de communications di-

F IGURE 2.1 – Principaux types de communication V2X

haute dynamicité de la topologie réseau, des connexions/déconnexions fréquentes, du

2.3 Un objectif : Les Systèmes de Transport Intelligents

2.3.1 Les C-ITS, raison d’être des réseaux véhiculaires

2.3.2 Les applications C-ITS

2.3.2.1 Des applications nombreuses et variées

Grâce aux différents types de communication V2X, beaucoup d’applications sont

— la supervision de la santé : le but premier de ces services est de s’assurer du