Soutenance mémoire
RÉSEAU MAILLÉ SANS FIL
CHANGEMENT DE CANAL
Introduction
Pour modifier la topologie d’un WMN, un mécanisme de CS est requis pour permettre aux STA maillées (MSTA) d’utiliser un nouveau canal. Lorsqu’un CS est initié, une MSTA transmet un nombre suffisant de CSA afin d’indiquer le nouveau canal qu’elle s’apprête à utiliser et le délai avant qu’il ne soit effectif. Ce délai permet de synchroniser les CS pour maintenir la connectivité entre les MP et le portail. L’initiateur d’un CS devrait donc fixer ce délai de manière à assurer un temps adéquat à la propagation des CSA dans le WMN. Or, pour convenir à des topologies variées sous différentes charges et pour conserver une marge de sécurité, l’initiateur d’un CS pourrait inutilement fixer un délai excessif et gaspiller un temps considérable. Le problème n’est pas seulement la valeur du délai, mais aussi le recours à un délai. Idéalement, un CS devrait s’effectuer dès que son initiateur sait qu’il ne nuira pas aux autres MP du réseau. Par conséquent, lorsqu’un CS est initié, le défi est d’éviter de gaspiller du temps et de maintenir la connectivité entre les MP et le portail.
Ce chapitre décrit un mécanisme de CS multiple pour des WMN multiradios basés sur la norme IEEE 802.11. Ce mécanisme permet de réduire le temps requis pour changer de canal en transmettant des CSA seulement aux MP concernés et en éliminant le délai servant à synchroniser les CS. De plus, pour maintenir la connectivité entre les MP et le portail pendant des CS simultanés, ce mécanisme empêche un MP de changer de canal avant qu’il ait transmis toutes les requêtes de CS qu’il a reçu.
Changement de canal
IEEE 802.11
La norme IEEE 802.11 permet de changer le canal opérationnel d’un ensemble de service de base (BSS), mais requiert que les perturbations causées par les CS soient minimisées (quoique la possibilité que certaines STA subissent des effets négatifs subsiste). Pour minimiser ces perturbations, l’AP d’un BSS doit 1-) essayer de choisir un canal1 qui est supporté par toutes les STA associées, 2-) annoncer son intention de changer de canal afin de maintenir les associations avec les STA et 3-) planifier le moment du CS pour que toutes les STA dans un BSS, incluant celles en mode économie d’énergie (PSM), puissent recevoir au moins un CSA avant le CS effectif. Utilisé dans une trame spécifique, dans une balise ou dans une trame Probe Response, un CSA permet de signaler aux STA associées le moment et le nouveau canal que l’AP d’un BSS s’apprête à utiliser. Le moment est calculé en nombre de temps de transmission de balise cible (TBTT) jusqu’au CS effectif de l’AP. Dans un BSS infrastructure, seul un AP peut initier un CS. Tel que défini dans le modèle en couches du protocole de gestion du spectre de la norme IEEE 802.11 (voir Figure 4.1), les politiques de décision résident dans le SME, mais la chronologie du CS réside dans l’entité de gestion de la couche MAC (MLME). Lorsqu’un CS est initié par un AP, le SME génère une primitive au MLME pour demander un CS. À la réception de cette primitive, le MLME planifie le moment approprié du CS et transmet un nombre suffisant de CSA. (Le nombre de CSA est discuté à l’ANNEXE IV.) Lorsqu’une STA associée dans un BSS reçoit un CSA, le MLME génère une primitive pour indiquer au SME la réception d’un CSA valide. À la réception de cette primitive, le SME doit décider s’il accepte (ou pas) de changer de canal. S’il décide de changer de canal, le SME génère une primitive au MLME pour confirmer qu’il accepte le CS. À la réception de cette primitive, le MLME planifie le moment approprié du CS. Au moment approprié d’effectuer le CS, le MLME génère une primitive au PLME pour fixer l’attribut dot11CurrentFrequency de la base d’informations de gestion (MIB). À moins qu’une transmission ne soit déjà en cours, le PLME génère une primitive au MLME pour confirmer la modification de l’attribut après au plus dot11ChannelSwitchTime. À la réception de cette primitive, le MLME génère une primitive au SME pour confirmer le résultat du CS. Un résumé du fonctionnement du mécanisme de CS et de l’utilisation du CSA est illustré dans le diagramme de séquence suivant (voir Figure 4.2). Il est à noter que sur réception d’un CSA, une STA associée pourrait décider de ne pas changer de canal et plutôt de joindre un autre BSS. De plus, sans recevoir de CSA, une STA pourrait momentanément se retrouver isolée.
IEEE 802.11s
L’amendement IEEE 802.11s permet de changer le canal opérationnel d’une MSTA, mais pour utiliser les maillages existants avec un nouveau canal, une MSTA doit 1-) annoncer son intention de changer de canal afin de maintenir ses liens maillés avec les MSTA paires et 2-) planifier le moment du CS pour que toutes les MSTA du MBSS, incluant celles qui ne désirent pas changer de canal, puissent recevoir un CSA avant le CS effectif. Comme pour un réseau IEEE 802.11, un CSA permet de signaler aux MSTA d’un MBSS le moment et le nouveau canal qu’une MSTA s’apprête à utiliser. Toutefois, contrairement à un réseau IEEE 802.11, le moment n’est plus calculé en nombre de TBTT, mais en TU. Le CSA spécifie également une valeur de préséance afin de gérer les CS simultanés. Cette valeur aléatoire est calculée à partir d’une distribution uniforme de manière à minimiser la probabilité de générer le même nombre, même lorsque des MSTA sont soumises à des conditions initiales identiques.
Dans un MBSS, chaque MSTA peut initier un CS. Comme pour les réseaux IEEE 802.11, les politiques de décision résident dans le SME et la chronologie du CS réside dans le MLME (voir Figure 4.1). Lorsqu’un CS est initié par une MSTA, le SME génère une primitive au MLME pour demander un CS. À la réception de cette primitive, le MLME planifie le moment approprié du CS et transmet un nombre suffisant de CSA. Lorsqu’une MSTA paire dans un MBSS reçoit un CSA, le MLME génère une primitive pour indiquer au SME la réception d’un CSA valide. À la réception de cette primitive, le SME doit vérifier s’il y a un CS en cours. S’il n’y a pas de CS en cours, la MSTA doit ignorer la valeur de préséance reçue dans le CSA et décider si elle accepte (ou pas) de changer de canal. Sinon, la valeur de préséance reçue dans le CSA est comparée avec la valeur de préséance de la MSTA réceptrice. Si la valeur de préséance reçue dans le CSA est inférieure ou égale à la valeur de préséance de la MSTA, alors la MSTA doit ignorer le CSA. Si la valeur de préséance reçue dans le CSA est plus grande que la valeur de préséance de la MSTA, alors la MSTA doit décider si elle accepte (ou pas) de changer de canal. Si la MSTA décide de changer de canal, le SME génère une primitive au MLME pour confirmer qu’il accepte le CS. À la réception de cette primitive, le MLME planifie le moment approprié du CS et transmet un CSA à chaque MSTA paire. Jusqu’au CS effectif, un CSA est aussi inclus dans les balises maillées et dans les trames Probe Response. Par la suite, le CS se déroule comme pour une STA dans un BSS (voir Figure 4.2).
Mécanisme de CS proposé
Le mécanisme de CS proposé dans ce chapitre permet de changer le canal d’une seule MSTA, de plusieurs MSTA en utilisant un canal commun, ou de plusieurs MSTA en utilisant des canaux multiples. Pour utiliser les maillages existants avec un nouveau canal, une MSTA doit toujours annoncer son intention de changer de canal afin de maintenir ses liens maillés avec les MSTA paires, mais il n’est plus nécessaire de planifier le moment du CS effectif. Contrairement aux mécanismes précédents, un CSA permet seulement de signaler aux MSTA d’un MBSS le nouveau canal qu’une MSTA s’apprête à utiliser. Le délai pour permettre la propagation des CSA dans le réseau et la valeur de préséance afin de gérer des CS simultanés ne sont pas utilisés. Les CSA indiquent aux MSTA réceptrices d’éventuelles perturbations sur des liens maillés. Si une NIC émettrice et une NIC réceptrice ne changent pas de canal sensiblement au même moment, leur lien se rompt et plus aucune communication directe n’est possible entre ces MP, à moins que leurs NIC colocalisées n’aient un lien ensemble. De plus, si une NIC émettrice est sur le chemin menant au portail d’une NIC réceptrice, alors la NIC réceptrice doit sélectionner un autre portail ou choisir un autre chemin pour atteindre le même portail. La NIC émettrice doit toujours sélectionner un autre chemin.
|
Table des matières
INTRODUCTION
CHAPITRE 1 RÉSEAU MAILLÉ SANS FIL
1.1 Introduction
1.2 Motivation
1.3 Problématique
1.3.1 Capacité
1.3.2 Bande passante
1.3.3 Topologie
1.3.4 Équité
1.3.5 Canal radio
1.4 Objectif
1.5 Méthodologie
1.6 Contraintes
1.6.1 Compatibilité
1.6.2 Interopérabilité
1.6.3 Capacité
1.6.4 Extensibilité
1.6.5 Performance
1.7 Structure du document
CHAPITRE 2 ARCHITECTURE
2.1 Introduction
2.2 WMN infrastructure
2.3 Point de service maillé
2.4 Mécanismes centralisés
2.5 Protocole de signalisation
2.6 Composantes multiradios
2.7 Cartes d’interface réseau
2.8 Topologie
2.8.1 IEEE 802.11a
2.8.2 IEEE 802.11cr
2.9 Interopérabilité
2.10 Conclusion
CHAPITRE 3 FORMATION DE TOPOLOGIES MAILLÉES
3.1 Introduction
3.2 Formation de topologies maillées
3.2.1 Auto-configuration
3.2.2 Découverte des nœuds voisins
3.2.2.1 Balayage passif (PS)
3.2.2.2 Balayage actif (AS)
3.2.3 Mécanisme distribué
3.2.4 Mécanisme centralisé
3.3 Évaluation de la performance
3.3.1 Description du réseau
3.3.2 Description des scénarios
3.3.3 Paramètres de simulation
3.4 Résultats
3.4.1 Balayage passif
3.4.2 Balayage actif
3.4.3 Mécanisme distribué
3.4.4 Mécanisme centralisé
3.5 Revue de la littérature
3.6 Conclusion
CHAPITRE 4 CHANGEMENT DE CANAL
4.1 Introduction
4.2 Changement de canal
4.2.1 IEEE 802.11
4.2.2 IEEE 802.11s
4.2.3 Mécanisme de CS proposé
4.2.3.1 Centralisation
4.2.3.2 Répartition
4.3 Évaluation de la performance
4.3.1 Description du réseau
4.3.2 Description des scénarios
4.3.2.1 Topologie optimisée
4.3.2.2 Topologie d’évitement
4.3.2.3 Topologie restaurée
4.3.3 Paramètres de simulation
4.4 Résultats
4.4.1 Topologie optimisée
4.4.2 Topologie d’évitement
4.4.3 Topologie restaurée
4.5 Revue de la littérature
4.6 Conclusion
CHAPITRE 5 ORDONNANCEMENT DES PAQUETS DE DONNÉES
5.1 Introduction
5.2 Ordonnancement
5.2.1 Aperçu
5.2.2 DWRR
5.2.3 AMH-DWRR
5.2.3.1 Variante 1: double déficit, quantum adaptatif
5.2.3.2 Variante 2: double déficit, taux adaptatif
5.2.3.3 Variante 3: simple déficit, quantum adaptatif
5.3 Évaluation de la performance
5.3.1 Description du réseau
5.3.2 Description des scénarios
5.3.3 Paramètres de simulation
5.3.4 Description du trafic
5.3.5 Description des queues
5.4 Résultats
5.4.1 Équité
5.4.2 Bande passante gaspillée
5.4.3 Débit
5.4.4 Bande passante allouée
5.5.1 Ordonnancement
5.5.2 Gestion active des queues
5.5.3 Modification de TCP
5.5.4 Modification de TCP/IP
5.6 Conclusion
RECOMMANDATIONS
Télécharger le rapport complet
