espace utilisateur
5. Architecture Orientée Web Services
6.6. Architecture de communication Cross-Layer
Dans le chapitre 4, nous avons défini une architecture de communication cross‐layer pour les réseaux sans fil, l’objectif de cette architecture étant de mettre à disposition des données présentes à différents niveaux de la pile protocolaire. L’ensemble des fonctionnalités fournies par cette architecture sont testées. Cependant, dans cette partie, nous allons présenter les tests fonctionnels de deux des fonctionnalités : l’enregistrement et la mise à jour de données (NF). Concernant, les tests de performance, il s’agit plus précisément de la capacité des communications cross‐layer à optimiser le système selon la situation et les besoins. Par conséquent, nous considérons que les résultats précédemment présentés sur les communications cross‐layer représentent ces tests de performance. 6.6.1. Scénario d’expérimentation
La généricité de l’architecture proposée lui permet de fonctionner avec n’importe quel type de technologie réseau du nœud de communication (Ethernet, Wifi, Wimax, Satellite, etc.). Dans un souci d’intégration, nous choisissons de l’appliquer au réseau Wifi 802.11 pour les expérimentations. Nous mettons en place une plate‐forme wifi 802.11 : un ordinateur portable possédant une interface wifi est connecté (sans fil) à un point d’accès wifi.
À partir de cette plate‐forme, nous installons notre architecture cross‐layer au sein de l’ordinateur portable et proposons de mettre à disposition plusieurs données :
• au niveau socket : un compteur d’utilisation des sockets netlink ;
• au niveau transport : la longueur des buffers et les flags utilisés dans le protocole TCP ; • au niveau physique : la qualité du signal, le SNR, et la proportion de bruit sur le driver de
carte Wifi.
La couche liaison est celle de l’interface réseau sans fil 802.11, dont le chipset est Intel Pro WLAN 3945. Ce dernier fonctionne sous le système Linux 2.15.20 et utilise le pilote réseau iwlwifi‐1.2.25. Nous modifions le code source de ce pilote réseau afin de mettre à disposition les trois paramètres concernant le signal sans fil.
Afin vérifier le bon fonctionnement de l’architecture, nous proposons de visualiser des messages d’état, introduits dans les 3 parties de l’architecture :
Pour les parties I_noyau et CL_entity, étant au niveau utilisateur, leurs messages sont affichés directement dans leur console de lancement respective. Pour la troisième partie présente dans l’espace noyau, nous utilisons l’interface du protocole « syslog » [97] communément déployé sur les systèmes Unix/Linux. Ce protocole client/serveur est initialement conçu pour la gestion de systèmes d’ordinateur et le contrôle de sécurité. Il permet de transmettre des messages d’alerte et/ou d’information de bas niveau, au sein d’un même ordinateur ou encore à travers un réseau IP. Notre entité dans l’espace noyau se comporte en client et envoie ses messages au serveur syslog qui lui, les affiche à l’écran.
6.6.2. Validation fonctionnelle
6.6.2.1. Étape d’enregistrement des NF (données)
Lorsque l’ordinateur portable démarre, les différentes données NF concernées présentes au niveau noyau émettent leurs demandes d’enregistrement au I_noyau. La Figure 70 montre deux des trois demandes d’enregistrement : le NF NOISE_EMILIE pour le paramètre de bruit du canal et le NF SIGNAL_EMILIE pour la qualité du signal. Le champ suivant est la valeur du paramètre à l’enregistrement.
Figure 70 : : messages d'enregistrement des données au sein du noyau
Au sein de l’entité I_noyau (c.f. Figure 71), la fonction « process_msg_kernel » s’active afin de recevoir et traiter le message d’enregistrement provenant du noyau. Sur la Figure 71, nous voyons le cas du NF qualité du signal. Cette demande est ensuite encapsulée puis envoyée au CL_entity. Pour l’encapsulation : on retrouve le type du message, 3, qui correspond bien à une demande d’enregistrement de NF ; l’id, 105, l’identifiant de la communication ; le NFname, SIGNAL_EMILIE ; le champ data, 88, étant la valeur du signal lors de l’enregistrement (88%) ; et le hostname, hecate, qui est le nom de l’ordinateur portable.
Figure 71 : messages d'enregistrement des données au sein du I_noyau
Le CL_entity quant à lui, lance la méthode « ProcessMsg » afin de recevoir et centraliser l’ensemble des demandes d’enregistrement des NF provenant du I_noyau (c.f. Figure 72). Au niveau de l’interprétation de l’affichage du CL_entity, on retrouve les champs précédemment décrits pour l’entité I_noyau. Ici, les 6 données NF sont enregistrées auprès du CL_entity. Figure 72 : messages d'enregistrement des données au sein du CL_entity On remarquera que le bruit est initialisé à ‐127dBm à l’enregistrement. Cela veut dire que l’interface réseau wifi de l’ordinateur portable n’a pas pu l’estimer et que la qualité du signal n’est pas extraite du SNR (signal (dBm)‐noise (dBm)).
6.6.2.2. Étape de mise à jour des NF
Afin de vérifier la mise à jour correcte des NF enregistrés, nous choisissons de faire évoluer la qualité du signal perçue par l’interface wifi. Pour cela, nous éloignons (géographiquement) l’ordinateur portable (donc l’interface réseau) du point d’accès wifi.
Comme le montre la Figure 73, au fur et à mesure de l’éloignement, le noyau envoie la mise à jour de la qualité du signal au CL_entity (par l’intermédiaire du I_noyau). Nous voyons ainsi décroitre la valeur du NF NF de 90%, 62% jusqu’à 37%.
Figure 73 : messages de mise à jour de la qualité du signal au sein du noyau
6.6.3. Conclusion
Ces résultats ont permis de justifier le bon fonctionnement de l’architecture cross‐layer proposée dans ces travaux de thèse. Cette architecture permet d’enregistrer des paramètres puis de les mettre à disposition en recevant régulièrement les mises à jour des valeurs. À partir de ces mises à jour reçues, la couche applicative est en mesure d’effectuer des opérations appropriées, telles que la recherche de nouvelles cellules wifi, ou encore la fermeture anticipée de connexions au niveau application, ou encore la gestion des connexions au niveau transport, tel que dans TCP.