IPv6 sans modifications de IPv6. Il adapte l’auto-configuration d’adresse SLAAC (stateless address auto-configuration)[87] déja connue dans IPv6 et étend le concept de lien IPv6 à des zones géographiques qui sont associées à un point d’attachement IPv6. GN6 introduit une sous-couche d’adaptation, nommée GN6ASL (GeoNetworking to IPv6 Adaptation Sub-Layer).qui présente une topologie de réseau plate à IP [23].
Le réseau ad hoc ITS doit assurer l’acheminement des paquets IPv6 amélioré par GeoNetworking pour assurer la communication entre les stations ITS. L’envoi des paquets IPv6 peut se faire par exemple par l’encapsulation de ces paquets IPv6 au niveau de l’entête du paquet GeoNetworking, le routage de ces paquets encapsulés se fait par le protocole GeoNetworking. Pour la couche IPv6, les stations ITS apparaissent attachées au même lien IPv6. L’accès à l’infrastructure (ex. communication avec des nœuds IPv6 sur Internet) nécessite des mécanismes spécifiques qui permettent la configuration d’une adresse IPv6.
Par ailleurs, dans un contexte de mobilité, l’accès d’une station ITS à une information au niveau de l’infrastructure de communication (ou l’inverse) nécessite que le concept d’IPv6 sur GeoNetworking soit amélioré pour supporter la mobilité IP.
2.8 Conclusion
Dans ce chapitre, nous avons résumé les études connexes qui ont été proposées dans le domaine des réseaux de véhicules par le standard européen ETSI et plus particulièrement (a) cette architecture est commune pour ETSI et ISO ([38] et ISO 21217 :2010) avec les différentes
applications (b) et les communications géographiques et IP à travers la pile protocolaire d’ETSI. Plusieurs types d’applications ITS ont été abordés par le standard ETSI et leurs exigences ont été spécifiées. Nous avons étudié le principe de Mobile IP et Proxy Mobile IP dédiés à la gestion de la mobilité.
Dans ce travail, nous nous sommes principalement intéressés aux applications de la sécurité routières qui nécessitent des mécanismes bien particuliers. Nous contribuons plus spécialement aux mécanismes de transmission multi-sauts au niveau de la couche réseau avec un contrôle de la congestion, ensuite à l’adressage hybrides (Géographique et IP) pour la gestion de la mobilité dans VANET.
Chapitre 3
Mécanismes de contrôle de la congestion
décentralisé (DCC) dans GeoNetworking
3.1 Introduction
Dans ce chapitre, nous adressons le problème de la dissémination en géobroadcast dans les réseaux à forte densité. Nous proposons, un protocole de routage géographique CBF2C, qui assure la transmission multi-saut des paquets avec un certain nombre de retransmission en se basant sur l’état de la congestion du canal radio. Motivé par cela, dans un premier temps, nous abordons la congestion du canal lors du transfert de paquets DENM. Ensuite, nous nous sommes intéressés à l’étude de la congestion du canal lorsque les paquets CAM et DENM partagent la ressource sans fil avec et sans DCC sur les messages CAMs. Ensuite, nous proposons d’améliorer le mécanisme CBF avec un contrôle de la congestion distribuée sur les messages DENMs (nommé CBF2C).
D’abord, dans la section 3.2 nous présentons le contexte globale et nous expliquons la problématique étudiée. Un état de l’art sur DCC est présenté dans la section 3.3. Dans la section 3.4 une étude des algorithmes de transmission multi-saut proposés dans le cadre de ETSI, qui permet de motiver notre travail. Elle décrit le principe de chaque algorithme de transmission multi-sauts avec leurs points forts et leurs faiblesses. Dans les sections3.5 et3.6
nous décrivons nos approches CBF2Cv1 et CBF2Cv2. Ensuite, nous présentons une évaluation de performances pour la validation de nos propositions dans les sections3.9,3.8et3.7. Enfin, nous résumons nos contributions en conclusion de ce chapitre.
3.2 Contexte global et Problématique
De nombreuses applications ITS nécessitent un transfert multi-sauts du message de notification DENM. Les algorithmes de transmission multi-sauts sont conçus sans considération du problème de la congestion et ils ont un impact négatif sur les systèmes de véhicules IEEE 802.11p, qui souffrent déjà de la congestion du canal causée, par exemple, par
les messages de sensibilisation coopérative (CAM).
En raison du fait que la ressource du canal soit limitée dans la bande de 5.9 GHz, la congestion du canal est l’un des problèmes clés du système réseau véhiculaire 802.11p. Le problème de congestion du canal causé par les CAM est bien connu [17, 83, 28]. Les études précédentes montrent que le PDR (taux de paquets reçus) peut se réduire à 50% et que le délai de la transmission de bout en bout (E2ED) peut augmenter à 1 seconde lorsque chaque véhicule diffuse périodiquement des messages CAM à 10 Hz avec une densité de 50 à 400 véhicules/Km2 [83]. Ce niveau de qualité de la communication ne peut évidemment pas satisfaire les exigences des applications de sécurité routière critiques à temps réel.
En ce qui concerne ce problème de la congestion du canal, ETSI a spécifié un framework de contrôle de la congestion distribuée (DCC) [17], une architecture qui permet aux stations ITS (nœuds) de contrôler leurs paramètres de communication au niveau de la couche accès, réseau ou facilities, comme illustré sur la Fig. 3.1. Un certain nombre d’efforts ont été fournis pour le contrôle de la congestion du canal en adaptant quelques paramètres au niveau de la couche facilities (en particulier la fréquence de transmission des CAM) et au niveau de la couche accès (y compris la puissance d’émission, contrôle de débit (Data rate control)et contrôle du seuil de détection de porteuse (carrier sense threshold) [26]. Cependant, au mieux de nos connaissances, il n’y a pas beaucoup de travaux pour le contrôle de la congestion au niveau de la couche réseau, approprié au framework ETSI.