FLASH INFORMATIQUE FI

Projet KTI/CTI no 6546.1 FHS-ET


Autonomous Wireless LAN Management




Jean-Frédéric WAGEN

Vincenzo INGUSCIO

Eric MARCHON


Résumé

Les Wireless Local Area Networks (WLAN) deviennent de plus en plus populaires. Standardisés dès 1999 par l’IEEE sous les normes 802.11b, g, et a, ces technologies connues sous le nom grand public Wi-Fi [1]-[3], permettent l’interconnexion d’ordinateurs grâce à un réseau sans fil. Les WLANs connaissent depuis le début des années 2000 un essor fulgurant chez les privés, dans les entreprises et notamment, en émergeant sous la forme de Hot Spots pour l’accès public à l’Internet. Un tel déploiement de bornes d’accès, appelées APs (Access Points) conduit au problème de l’allocation des 11 canaux radio définis dans la bande ISM (Industrial, Scientific & Medical) dont l’utilisation peut se faire sans licence. La norme 802.11b ne prévoit pas de système automatique de répartition de ces canaux. Ainsi, un tel système a été développé dans le cadre d’un projet de diplôme à l’école d’ingénieurs et d’architectes de Fribourg (EIA-FR) puis lors du projet KTI/CTI no 6546.1 grâce à la collaboration de Swisscom Innovations et de l’EPFL. Le système développé permet une répartition optimale des canaux radio. Le développement a abouti à une application distribuée et autonome permettant la gestion de ces canaux et pouvant fonctionner aussi bien dans le contexte d’opérateurs WLAN que dans celui d’une entreprise. Le système a été nommé Resource Management Engine (RME). L’objectif du RME est d’obtenir la meilleure qualité de service (QoS). Ainsi le RME optimise la répartition des canaux radio afin de minimiser les interférences pour assurer des débits aussi élevés que possible sur chaque AP. Le processus d’optimisation du RME est basé sur les informations disponibles dans les APs. Le protocole SNMP [4]-[5] (Simple Network Management Protocol) est utilisé pour mesurer les paramètres nécessaires aux processus d’optimisation. Le protocole SNMP est aussi utilisé pour configurer le canal radio de chaque AP. Le processus d’optimisation du RME a été mis en oeuvre en JAVA dans l’environnement flexible et évolutif que sont les agents logiciels ou software agents [6]. Les agents RME ont été testés dans un environnement de simulation développé à l’Université de Fribourg [9]. D’autres tests de performances sont en cours à l’EPFL. L’approche proposée a été testée puis mise en service sur le réseau WLAN de l’EIA-FR. Sur ce réseau de 16 APs, le RME adapte automatiquement la répartition des canaux radio. les principes impliqués dans le RME sont protégés par le brevet no 03405356.1 [13]. Ce papier contient une brève description du RME et de ces tests.

Le problème d’allocation des fréquences WLAN

fig. 1 - spectre du WLAN 


Les 83.5 MHz de la bande ISM utilisée par les équipements WLAN est partagée en 13 canaux se chevauchant selon la figure 1. Un canal WLAN pour le Wi-Fi /802.11b occupe une largeur de bande d’environ 22 MHz. Cette largeur de bande est utilisée pour transmettre des débits de 1, 2, 5.5 ou 11 Mb/s en utilisant une technique d’étalement du spectre (Direct Sequence Spread Spectrum). Comme l’indique la figure 1, seul les trois canaux 1,6 et 11 ne s’interfèrent pas parmi les 11 premiers canaux qui sont utilisables dans pratiquement le monde entier. Il est donc nécessaire de séparer d’au moins cinq canaux les APs dont les couvertures radio se superposent. Ainsi, les canaux 1, 6, et 11 sont les plus souvent utilisés. De plus, il est très difficile en pratique d’utiliser les autres canaux de manière efficace car les interférences dépendent entre autre des équipements (APs et clients) et du trafic.
Examinons un scénario concret comme celui décrit dans la figure 2 pour illustrer le problème de l’allocation des canaux Wi-Fi.
Admettons une allocation manuelle initiale sur les trois premiers APs : soit AP1, AP2 et AP3 avec les canaux 1, 11, et 6. Ainsi : freq(AP1)=1, freq(AP2)=11 et freq(AP3)=6. Cette solution permet d’offrir un maximum de QoS (Quality Of Service). Elle n’est pas unique mais a été choisie comme exemple. Considérons maintenant qu’un 4ème AP (AP4) est installé à l’image de la figure 2. Quel canal faut-il attribuer à AP4 pour obtenir un minimum d’interférences afin d’offrir un maximum de QoS ? Il est impossible d’attribuer un canal sans créer de perturbations. Mais en changeant l’allocation des fréquences sur AP2 et AP3, il est possible de disposer d’un canal presque libre de toute perturbation car les couvertures des AP2 et AP4 ne se chevauchent que très peu. Ainsi, une nouvelle attribution sur les APs 2 et 3 : freq(AP2)=6 et freq(AP3)=1 permet d’attribuer le canal 11 à l’AP4 en minimisant les interférences.

fig. 2 - illustration d’une solution au problème de la superposition des couvertures radio dans un exemple simple 


En pratique, dans le réseau WLAN de l’EIA-FR décrit dans la figure 2 par exemple, les couvertures et les interférences sont beaucoup plus complexes et dépendent aussi de la charge de trafic sur chaque AP. Ainsi la répartition optimale des canaux peut être non seulement difficile à obtenir manuellement, mais elle varie dans le temps en fonction de la charge du réseau par les utilisateurs. C’est pourquoi le RME a été réalisé pour effectuer les allocations de canaux d’une manière adaptative, automatique et optimale. Une mise en oeuvre distribuée du RME a été choisie au lieu d’une solution centralisée afin de faciliter son utilisation sur un grand nombre d’APs. Le RME est décrit dans les sections suivantes en considérant sa mise en oeuvre dans un réseau WLAN fonctionnel.

fig. 3 -infrastructure WLAN de l’EIA-FR 


L’infrastructure de test pour le RME

La figure 3 décrit le réseau WLAN de l’EIA-FR et la mise en oeuvre du RME dans cet environnement. L’EIA-FR est composée de plusieurs bâtiments dont 4 sont équipés du WLAN pour un total de 16 APs. Tous les APs sont reliés sur le même sous réseau. D’un point de vu logique, chaque agent logiciel du RME gère un AP. Comme il s’agit d’un système distribué, le choix fut d’attribuer un PC par bâtiment. Chaque PC supporte l’environnement nécessaire aux agents logiciels [6]. En résumé, le RME se trouvent sur un sous-réseau interne à l’EIA-FR (VLAN30) et pilote le réseau WLAN (VLAN160) en utilisant le protocole SNMP. La section suivante donne plus de détails sur le RME.

L’approche agent

fig. 4 - l’agent RME 


Le système RME est basé sur des agents logiciels afin d’assurer un déploiement simple quelle que soit l’échelle du réseau WLAN. La plate-forme logicielle pour les agents RME a été choisie sur la base d’expériences et de projets réalisés à Swisscom et à l’EIA-FR. Ainsi, le choix pour supporter les agents RME s’est dirigé vers JADE [6]. Cette plate-forme est issue d’une organisation open source et écrite entièrement en JAVA. JADE est conforme au standard FIPA. La plate-forme multi agents JADE dispose de plusieurs mécanismes pour l’échange de messages asynchrones entre agents. Classiquement, nous définissons un agent comme un logiciel exécutant des tâches spécifiques et possédant un degré d’intelligence qui lui permet de gérer ces tâches de manière autonome et d’interagir avec son environnement de façon appropriée. Les agents logiciels possèdent un ou plusieurs comportements (Behaviours) simultanés dont la concurrence est gérée grâce aux JAVA Threads dont JADE est issue. Les agents RME possèdent deux comportements exécutés en parallèles : le MonitorBehaviour et le MsgBehaviour. Le MonitorBehaviour lit continuellement les données de l’AP qu’il contrôle pour évaluer l’environnement dans lequel l’AP évolue.
Le MsgBehaviour lit les messages reçus des autres agents RME. Ces messages sont de deux types :
• inform : annonce de changements par un autre AP, ou
• management : pour la gestion des agents par la plate-forme JADE.
L’agent RME, grâce aux données fournies par ces deux comportements, détermine le canal le plus approprié suivant un algorithme d’optimisation et affecte ce canal à l’AP qu’il gère. Pour diminuer la place mémoire requise en vue d’une implémentation sur du matériel embarqué ou d’une intégration dans le progiciel de l’AP, la plate-forme JADE-LEAP a été utilisée. JADE-LEAP offre un noyau qui a été adapté pour différents environnements [6] : J2SE pour des ordinateurs de bureau, des stations de travail ou certains systèmes embarqués (TINI [12] par exemple), J2ME-PJava pour des systèmes plus limités comme des petits ordinateurs (PDA par exemple), et J2ME-MIDP/CLDC pour d’autres systèmes embarqués (SNAP [11] par exemple avec modifications car il ne supporte pas MIDP) ou des téléphones mobiles (smartphone par exemple).
L’algorithme d’optimisation [13] et son paramétrage ne sont pas décrits ici afin de garder une vue d’ensemble du RME. Les concepts de bases de l’algorithme d’optimisation sont les fruits de discussions avec l’EPFL et Swisscom Innovations. Le développement de cet algorithme est la contribution principale de l’EPFL et de Sacha Varone en particulier. La première phase d’évaluations de l’algorithme d’optimisation sera terminée à fin 2003. Une mise en oeuvre et certains paramétrages pratiques ont été réalisés sur la base de simulations, décrites dans la section suivante, et d’expériences réalisées à Swisscom Innovations, puis à l’EIA-FR.

Simulations du RME

Pour tester la mise en oeuvre et la stabilité de l’algorithme d’optimisation, le Generic Network Management Tool (GNMT [9]) a été utilisé. Les interfaces conviviales du GNMT et son extension réalisée par Daniel Rossier (Swisscom Innovations) pour la couche du WLAN ont permis de rapidement procéder aux tests décrits brièvement ci-dessous (figure 5).

fig. 5 -simulation avec le GNMT (Generic Network Management Tool) 


Dans la figure 6, les liens entre 2 noeuds (APs) du réseau représentent l’existence des interférences qu’il pourrait y avoir si les canaux de ces 2 APs étaient trop proches l’un de l’autre. La couleur du lien (niveau de gris dan les figs 5-10) indique le degré d’interférences entre les 2 APs. Chaque lien possède un poids, normalisé entre 0 et 1, qui définit le niveau de perturbations dé à la proximité géographique des 2 APs. Par exemple : si 2 APs sont en ligne de vue, le poids est de 1 mais si les APs sont séparés par un mur, le poids serait de 0.5. La mise en place des poids se réalise aisément pour les simulations grâce au GNMT.
Le GNMT avec sa couche WLAN facilite aussi l’utilisation des agents logiciels et nous avons pu y intégrer les agents RME. Ainsi des tests fonctionnels ont pu être validés sur plusieurs réseaux WLAN simulés.
Une des limitations actuelles du GNMT est l’adaptation des données (MIBs)8 lors de modifications des canaux radio par les agents du RME. Ces données sont accessibles en pratique grâce au protocole SNMP [4-5] mais ces valeurs sont simulées dans le GNMT. La section suivante décrit ces aspects de la gestion d’un réseau WLAN par le RME.

Le management de réseau

Le SNMP (Simple Network Management Protocol) est devenu le standard de facto pour la gestion des équipements sur réseau IP. Le SNMP se base sur le modèle client - serveur entre le manager, ici l’agent RME, et l’agent SNMP qui se trouve dans l’AP. La terminologie agent est source de confusion mais c’est celle qui est officiellement utilisée. Les données lues par le MonitorBehaviour sont des informations contenues dans les objets d’une MIB [7]-[8]. Les MIBs peuvent être considérées comme des bases de données, dans lesquelles les caractéristiques d’un équipement, ici un AP, sont stockées dans une structure en arbre.
Les deux opérations effectuées par l’agent RME sur la MIB de son AP sont le GET et le SET. L’opération GET permet à l’agent RME de récupérer une valeur contenue dans la base de données de l’AP. L’opération SET permet d’assigner un canal radio particulier. Dans ce dernier exemple, c’est l’élément dot11CurrentChannel de la MIB standard des équipements Wi-Fi (IEEE 802.11b) qui est utilisé. On remarquera la description quasi-intuitive de cet élément. Ce n’est malheureusement pas toujours aussi clair pour d’autres données nécessaires au fonctionnement du RME. Ainsi des adaptations doivent être réalisées pour configurer un agent RME aux spécificités d’un constructeur ou d’un type d’AP particulier.

Le Resource Management Engine (RME)

Les sections précédentes ont décrit le RME. Un agent RME, représenté dans la figure 4, comporte 3 parties principales (voir la section L’approche agent en page 11 pour les définitions) :
• le MonitorBehaviour,
• le MsgBehaviour, et
• l’algorithme d’optimisation.
Le système RME a été testé en simulation. Les résultats étant satisfaisants, une mise en pratique dans le réseau WLAN de l’EIA-FR a été réalisée. Les sections suivantes décrivent cette réalisation.

Description du réseau WLAN EIA-FR pour les tests du RME

La figure 6 présente précisément les 16 APs du réseau WLAN de l’EIA-FR, la répartition de ces APs dans les bâtiments nommés A, B, C et D et les différents étages (axe vertical). Dans le bâtiment A, il y a 4 APs, 2 dans le B, 6 dans le C et 4 dans le D. Dans la figure 6, chaque noeud (Node ou AP) indique son canal (Current Channel), le nombre de stations associées (NAS) et l’activité de l’AP (Activity). L’activité de l’AP a été définie par une fonction tenant compte du taux d’erreurs, du taux d’utilisation et du nombre de stations associées.

fig. 6 -visualisation du réseau WLAN de l’EIA-FR et des liens d’interférence entre APs 


La visualisation des résultats pratiques du RME représentée dans la figure 6 a été accomplie en modifiant l’interface graphique du GNMT ce qui explique la similarité avec la figure 5 qui décrit une simulation.
Afin de démontrer le bon fonctionnement du RME, nous avons documenté les tests suivants :

Démonstration : initialisation

fig. 7 - état initial du réseau WLAN 


Grâce à une commande de gestion spéciale du RME, les canaux des APs sont tous initialisés avec le canal 1 et les changements de canaux sont inhibés. Cet état permet aux agents RME de mettre à jour leurs données qui varient en fonction du voisinage de chaque AP, mais interdit toute modification des canaux. Le réseau WLAN est fonctionnel mais de nombreuses interférences diminuent l’efficacité. Une mesure de débit sur 2 PC portables associés à 2 APs différents (reliés par un lien d’interférence) donne par exemple 1 et 2 Mbps.
Le processus d’optimisation est ensuite libéré. Ce processus entraîne des modifications dans l’attribution des canaux. Après quelques dizaines de secondes un état stable est obtenu, lequel est visualisé dans la figure 8. L’optimisation du RME permet, par exemple, d’augmenter à 4 et 5.5 Mbps les débits mesurés ci-dessus. La configuration de la figure 8 dépend de la charge du réseau et, d’une manière aléatoire, de l’agent qui a commencé l’optimisation. Cet état est optimal mais n’est pas unique. En effet, plusieurs configurations optimales sont possibles comme dans le cas des 4 APs de la figure 2. D’autre part, la répartition optimale dépend de la charge et du trafic sur chaque AP. Ainsi une autre répartition optimale est obtenue une heure après, comme le montre la figure 9.

Démonstration : utilisateurs nomades

fig. 8 - état stable (à 9H00) 


fig. 9 - état stable (à 10H00) 


Comme exemple, analysons le bâtiment C, qui offre une vue concrète de la distribution des fréquences en fonction de la charge. Les deux APs de l’étage inférieur du bâtiment C (en bas dans les figures 8 et 9) ont obtenus le canal 11 (figure 8) car ils n’ont pas encore de stations associées alors que les autres APs obtiennent des canaux espacés les uns des autres là oà il y a le plus de charge (voir les canaux 1, 6 et 11).
La figure 9 reflète l’état du réseau une heure plus tard, alors que les personnes se sont déplacées vers les étages inférieurs.

Ainsi, à 10h, les deux APs de l’étage inférieur (qui, à 9h00, avaient le canal 11) ont dà s’éloigner l’un de l’autre pour diminuer leurs interférences mutuelles et offrir une meilleure bande passante. Les cercles indiquent les changements et la valeur obtenue par l’algorithme d’optimisation. Par rapport à une configuration statique, le RME permet une adaptation aux conditions de charge du réseau WLAN.
Les mesures ont montré qu’un utilisateur ne s’aperçoit pas des changements de canaux des APs, en particulier si la personne utilise Windows 2000 ou XP et que les APs permettent de commuter d’une fréquence à une autre en quelques millisecondes comme c’est le cas pour les APs Cisco Aironet 1100.

Démonstration : opérateur concurrent

fig. 10 - un opérateur concurrent se place à proximité de notre réseau WLAN 


Une autre illustration de l’avantage du RME dans un réseau WLAN est la prise en compte d’un opérateur externe ou concurrent venant perturber le réseau WLAN sous contrôle de RME. Considérons par exemple qu’un AP concurrent avec le canal 9 (voir AP encerclé dans la figure 10) est installé près des deux APs de l’étage inférieur. Cet AP concurrent n’a pas d’agent RME qui puisse le contrôler. Le problème de la découverte automatique d’un tel AP (concurrent ou non) n’étant pas encore résolu dans le projet, ce nouvel AP a été annoncé au réseau WLAN de l’EIA-FR par le biais du GNMT. Dès lors, une reconfiguration des canaux sur les deux APs interférés a pu s’opérer. La situation de la figure 10 présente le résultat de l’adaptation par le RME. L’AP qui avait le canal 11 a pris le canal 1 et l’autre AP est passé au canal 5. Les APs contrôlés par les agents RME se sont reconfigurés pour éviterles perturbations provoquées par l’AP concurrent. A noter que les liens d’interférences entre l’AP concurrent et les APs contrôlés par le RME ont été définis avec le poids maximal de 1 étant donné l’ignorance du degré de la perturbation. Ce dernier exemple montre l’avantage du RME dans le cas d’interférences non contrôlables. Actuellement, l’annonce manuelle des APs concurrents reste un inconvénient.

Conclusions

La faisabilité d’un système distribué et autonome permettant une répartition optimale et adaptée aux conditions de trafic et d’interférences dans un réseau WLAN a été démontrée. Le système appelé Resource Management Engine (RME) a été développé en JAVA sur une plate-forme distribuée d’agents logiciels JADE-LEAP.

L’efficacité des agents logiciels RME est établie par l’adaptation automatique à la charge du réseau WLAN, par la stabilité obtenue suite au processus d’optimisation, par la capacité de prendre en compte un AP concurrent et par la diminution observable des interférences. Des mesures de débit utile réalisées avec le scénario de l’AP concurrent montre une augmentation d’un facteur 5 pour les débits obtenus grâce au RME.

Au vu des expériences accumulées dans ce projet, deux améliorations ont été identifiées. La première amélioration, indispensable pour le gestionnaire d’un réseau WLAN, concerne la supervision des agents et leurs déploiements. La deuxième amélioration, concerne la découverte automatique du voisinage par les agents RME afin de réduire encore toute intervention manuelle.

fig. 11 - Le démonstrateur RME pour le WLAN de l’EIA-FR 


Remerciements

Les auteurs n’auraient pas pu accomplir le système présenté ici sans les contributions de :
• Daniel Rossier, chef du projet RME à Swisscom Innovations.
• François Buntschu, collaborateur scientifique EIA-FR, et WLAN manager.
• Fiorenzo Gamba, collaborateur scientifique EIA-FR, pour son suivi lors du projet de diplôme.
D’autre part les contributions d’Eric Demierre, Mohamed Mokdad, Ferran Moreno Blanca, et Sacha Varone (Swisscom Innovations), de Roger Lagadec (Swisscom Mobile) et récemment, de Frédéric Aviolat (EPFL) ont été fortement appréciées.

Références

[1] Standard pour réseau sans fil : 802.11, Daniel Trezentos, Ecole nationale supérieure des Télécommunications de Bretagne, http://www.techniques-ingenieur.fr/affichage/DispIntro.asp?nGcmId=TE7375

[2] A Technical Tutorial on the IEEE 802.11 Protocol, Pablo Brenner, Breezecom Wireless Communications, http://www.sss-mag.com/pdf/802_11tut.pdf
[3] IEEE Std 802.11, Part 11 : Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, including ieee802.11-mib, edition 1999 (http://ieee802.org/11/)
[4] Architecture SNMP, mémoire de Laurent Frank, Laurent Frank, Université libre de Bruxelles, 1998, http://www.f4dwu.net/download/memoire2.pdf
[5] RFC 1157, Simple Network Management Protocol (SNMP), May 1990
[6] Jade-LEAP (3.0b1, 19th March 2003), http://www.jade.cselt.it, Fabio Bellifemine, Giovanni Caire, Tiziana Trucco, TILab S.p.A., Giovanni Rimassa, Università di Parma
[7] RFC 1213, Management Information Base for Network Management of TCP/IP-based internets : MIB-II
[8] Cisco Systems, http://www.cisco.com
[9] A Description of the Generic Network Management Tool (GNMT), Daniel Rossier, Université de Fribourg et Swisscom Innovations, http://diuf.unifr.ch/pai/publications/2002/technical_report/ros_1002.pdf
[10] NLANR/DAST Projects, Ajay Tirumala, Feng Qin, Jon Dugan, Jim Ferguson, Kevin Gibbs, version 1.7.0, March 2003, http://dast.nlanr.net/Projects/Iperf/
[11] SNAP (Simple Network Application Platform), http://www.imsys.se , IMSYS AB, Sweden
[12] TINI (Tiny InterNet Interface), http://www.ibutton.com/TINI/ , Dallas Semiconductor Corporation, Tex
[13] Brevet Nr. 03405356.1, System für die dynamische Zuweisung von Tr&uumlgerfrequenzen zu Zugriffspunkten eines lokalen Funknetzes, Daniel Rossier, Sacha Varone, Swisscom Innovations, Jean-Frédéric Wagen, Vincenzo Inguscio, Eric Marchon, Fiorenzo Gamba, Ecole d’ingénieurs et d’architectes de Fribourg.





• 1 JADE : Java Agent DEvelopment Framework for multi-agent systems (compliance with FIPA)
• 2 FIPA : Foundation for Intelligent & Physical Agents
• 3 LEAP : Lightweight Extensible Agent Platform
• 4 J2ME-Pjava : Java 2 Micro Edition for Personal Java
• 5 J2ME-MIDP/CLDC : Java 2 Micro Edition for Mobile Information Device Profile/Connected Limited Device Configuration
• 6 devisé par Sacha Varone et modifié par Frédéric Aviolat (EPFL) dans le cadre du projet CTI/KTI.
• 7 Agent SNMP : progiciel mis en oeuvre par les constructeurs d’équipements réseaux pour la gestion à distance de ces équipements.
• 8 MIB : Management Information Base
• 9 Mesure de référence : tous les canaux à 1 et le canal 2 pour l’AP concurrent. Mesure avec RME : voir figure 10. Les mesures de la bande passante sur TCP/IP ont été réalisées avec les logiciels IPERF [10].



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.