3.2.1 Une approche modulaire
Face à la complexité du système considéré, celui-ci va être découpé en plusieurs parties afin de faciliter la construction du modèle, ainsi que son évolution.
Figure 3.8 – Exemple de transmission sur un réseau maillé
La transmission, sur un réseau WiFi maillé, peut être exprimée sur un plan topolo- gique ; chaque nœud a une position déterminée et ne peut communiquer qu’avec certains autres nœuds (figure 3.8). L’aspect coloré du formalisme de réseau de Petri que nous avons choisi permet de modéliser le comportement d’un nœud à partir de la structure du modèle et de représenter plusieurs nœuds à partir du marquage du modèle. De cette manière, le nombre de nœuds est donc facilement configurable. Chacun d’eux peut être une station ou un point d’accès. Ceci est aussi configurable.
La topologie est donc décrite par des jetons colorés, ce qui facilite la mise en place de différentes simulations. Le modèle est donc évolutif au sens de la topologie réseau qu’il représente. Ceci est important dans notre cas car le simulateur doit être exploitable sur différentes installations déployées ou à déployer par l’entreprise.
La transmission peut aussi être décomposée en fonction de la pile protocolaire, en suivant les couches du modèle TCP/IP. Pour une transmission qui doit aller d’un nœud 1 à un nœud 5 (figure 3.9) et devant être relayée par les nœuds 2, 3 et 4, les paquets sont encapsulés à chaque traversée de couche sur le nœud 1, chaque nœud intermédiaire
traite la retransmission au niveau de la couche Liaison, et enfin le nœud 5 désencapsule les données pour les délivrer à la couche Application.
Figure 3.9 – Exemple de transmission sur le modèle Internet
Le modèle est donc explicitement structuré selon ces couches. Afin de détailler da- vantage la couche liaison de données, elle est divisée en sous couche MAC et LLC. La sous couches MAC modélise les mécanismes propres à la norme WiFi, avec les méca- nismes d’accès au médium, alors que la sous couche LLC est utilisée pour la répétition de paquet, et le choix des chemins.
Les couches Réseau et Transport ne sont pas modélisées en détail car un paquet aura un nœud source et un nœud destination identifié au niveau MAC. Les notions d’adresses IP et de routage ne sont pas utiles dans le cadre de notre étude, néanmoins le modèle pourrait être enrichi si besoin est.
Enfin, deux applications permettant de générer des données ICMP et UDP seront implémentées. Un premier module nommé ICMP permet de générer des requêtes pé- riodiquement. Quand une requête atteint sa destination, une réponse est émise vers la source de la requête. Ainsi, le RTT peut être mesuré au travers du réseau maillé. Ce protocole permet tout d’abord de valider le fonctionnement du modèle, car un paquet simple est facile à suivre. De plus, ICMP permet de mesurer le RTT en même temps que d’autres transmissions transitent sur le réseau maillé.
Un second module générant des paquets est inscrit dans l’architecture du simulateur, il s’agit du module UDP. Comme le protocole du même nom, celui-ci permet de générer des paquets en spécifiant :
– le nombre,
– la date de mise en file d’attente d’émission, – la classe de qualité de service,
– la taille,
– les nœuds sources et destination.
Ainsi, différents types de trafic peuvent être générés avec ce module, qu’il soit périodique ou sporadique, représentant de la voix sur ip ou du téléchargement.
Structuration du modèle 49
Figure 3.10 – Transmission sur chaque nœud
Chaque nœud étant singularisé par une couleur différente, il n’est nécessaire de représenter qu’un seul modèle comportemental pour chaque couche, et celui-ci sera utilisé pour tous les nœuds grâce au principe du repliage et de la coloration. Ainsi, à partir de la figure 3.10, nous obtenons le modèle replié présenté figure 3.11.
Figure 3.11 – Repliage du modèle de la transmission
3.2.2 Présentation des modules
Le modèle général est nommé Network. Il a été raffiné au fur et à mesure de sa construction comme le présente la figure 3.12. Il est décomposé en plusieurs modules :
– Le modèle ICMP modélise une émission de requête périodique, comme le fait le programme ping. Le principe requête/réponse de ce protocole nous permet de mesurer des temps aller-retour (RTT). Cette fonctionnalité simple nous permet dans un premier temps de valider les principes de base du modèle : génération de paquet, transmission sur la couche radio, délais intertrames, période de contention, émission d’accusé de réception...
– Le modèle UDP décrit des émissions ponctuelles, avec différentes caractéristiques de paquet (qualité de service, temps nécessaire pour l’émettre...) de manière à injecter des trafics particuliers dans le modèle. Ceci permet de simuler d’une part des émissions périodiques de petits paquets comme le ferait un flux audio, et
d’autre part des transmissions de nombreux gros paquets comme le ferait un transfert de fichier.
– Le modèle LLC représente la partie haute de la couche liaison. C’est au sein de cette couche qu’est effectué le choix du chemin pour chaque paquet ainsi que la répétition de paquet.
– Le modèle MAC est spécifique au WiFi et implémente la partie basse de la couche liaison, avec la méthode d’accès, la gestion d’accusé de réception et l’émission périodique de beacon.
– Le modèle Radio décrit la couche physique.
Figure3.12 – Présentation des éléments du modèle
Au regard de l’influence du protocole MAC sur les échanges entre nœuds, le modèle MAC est le plus complexe. Il est aussi divisé en plusieurs modules :
– Beacon permet la diffusion périodique de beacon pour les nœuds de type point d’accès.
– AccessCategories modélise les quatre files d’attente de la norme 802.11e : VO (Voix), VI (Vidéo), BE (Best Effort), et BK (Background).
– Ifs impose aux paquets les délais intertrames correspondants.
– Contention décrit le tir ou non de période de contention ainsi que sa durée puis temporise le paquet en conséquence. De plus, il surveille l’utilisation du canal radio et réinitialise l’émission si une transmission est en cours comme le présente le mécanisme CSMA/CA.
– RecvAck gère les réceptions d’accusé de réception et décide de réémettre un paquet qui n’a pas été acquitté.
– MACReceive décrit la réception de paquet. En effet, ceci impacte le prochain délai intertrame. Ensuite, il ignore les paquets qui ne sont pas destinés à ce nœud. Puis il achemine les RTS, CTS et ACK au module ACKRTSCTS. Enfin, il propose les paquets de données à la couche LLC.
– SendWithSIFS permet d’émettre des paquets de contrôle à la suite d’un temps intertrame SIFS.
– ACKRTSCTS gère l’utilisation des paquets de contrôle RTS/CTS s’ils sont acti- vés, ainsi que l’émission d’accusé de réception.
Granularité 51