Coexistence entre WLAN 802.11 et Bluetooth - Dr Stephan Robert
Coexistence entre WLAN 802.11 et Bluetooth - Dr Stephan Robert
Coexistence entre WLAN 802.11 et Bluetooth - Dr Stephan Robert
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Coexistence</strong><br />
<strong>entre</strong><br />
<strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
Une étude réalisée par<br />
Karl Baumgartner <strong>et</strong> Jérôme Racloz<br />
Etudiants à l’EIVD<br />
Proposée <strong>et</strong> supervisée par<br />
Marcos Rubinstein<br />
Professeur à l’EIVD<br />
Expertisée par<br />
C. Monney<br />
Automne/Hiver 2002
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Résumé<br />
Deux technologies sans-fils destinées à l’informatique connaissent actuellement un<br />
énorme succès. Il s’agit de <strong>WLAN</strong> <strong>802.11</strong>b, aussi connue sous le nom de Wi-Fi, <strong>et</strong> de<br />
Blu<strong>et</strong>ooth. Chacune de ces technologies communique par ondes électromagnétiques <strong>et</strong><br />
utilise pour cela la même bande de fréquence à 2,4 GHz , appelée ISM. Donc lorsque<br />
que des dispositifs Wi-Fi <strong>et</strong> Blu<strong>et</strong>ooth communiquent simultanément dans le même<br />
environnement, il se produit des interférences qui entraînent des erreurs sur les paqu<strong>et</strong>s<br />
échangés. Ces erreurs engendrent des baisses de performances pour les deux<br />
technologies.<br />
Ce proj<strong>et</strong> a pour but de comprendre dans quelles conditions la coexistence <strong>entre</strong> <strong>WLAN</strong><br />
<strong>802.11</strong>b <strong>et</strong> Blu<strong>et</strong>ooth pose problèmes, de quantifier ces problèmes <strong>et</strong> d’y apporter des<br />
solutions. Seules les baisses de performances sur <strong>WLAN</strong> sont abordées dans ce<br />
document. L’étude de la coexistence <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong>b <strong>et</strong> Blu<strong>et</strong>ooth peut être vue<br />
en trois parties.<br />
La première partie consiste à étudier ce qui se passe au niveau de l'interface aérien<br />
(propagation des ondes, interférences). C<strong>et</strong>te partie est traitée au moyen d’un modèle<br />
statistique perm<strong>et</strong>tant de déterminer la probabilité d’avoir des interférences.<br />
La seconde partie traite du comportement de la couche physique de <strong>WLAN</strong> <strong>802.11</strong>b.<br />
Pour c<strong>et</strong>te partie, faisant intervenir les techniques de modulations à spectre étalé, une<br />
simulation sur Matlab c’est avérée nécessaire tant les calculs pour un modèle général<br />
aurait été compliqués.<br />
Finalement, il s’agit de déterminer de quelle manière sont traitées les trames erronées par<br />
Blu<strong>et</strong>ooth par les techniques d’accès au canal utilisées par <strong>WLAN</strong> <strong>802.11</strong>b. Les<br />
performances de <strong>WLAN</strong> <strong>et</strong> Blu<strong>et</strong>ooth sont obtenues par le calcul du débit réel lors<br />
d’une communication. Les calculs du débit, basés sur un modèle statistique, ont été<br />
effectués sous Java.<br />
Des mesures en plein air, ainsi que en chambre anéchoïque, viennent valider les résultats<br />
obtenus théoriquement. Et viennent en même temps confirmer que le problème de la<br />
coexistence <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong>b <strong>et</strong> Blu<strong>et</strong>ooth est bien réel. Les dégradations des<br />
performances constatées sur les communications <strong>WLAN</strong> sont importantes <strong>et</strong> la solution<br />
idéale reste à découvrir.<br />
2
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Table des matières<br />
1 INTRODUCTION.......................................................................................................... 11<br />
1.1 MOTIVATION............................................................................................................. 12<br />
1.2 OBJECTIFS ................................................................................................................. 13<br />
2 <strong>WLAN</strong> ............................................................................................................................. 16<br />
2.1 INTRODUCTION.......................................................................................................... 17<br />
2.2 WI-FI ..................................................................................................................... 18<br />
2.3 ARCHITECTURE DES RESEAUX <strong>802.11</strong> ....................................................................... 19<br />
2.4 SERVICES DES RESEAUX <strong>802.11</strong> ................................................................................ 21<br />
2.4.1 Station Serivce (SS) .......................................................................................... 21<br />
2.4.2 Distribution System Service (DSS)................................................................... 21<br />
2.5 STRUCTURE DU PROTOCOLE ...................................................................................... 23<br />
2.6 COUCHE MAC .......................................................................................................... 23<br />
2.6.1 Adresses............................................................................................................ 23<br />
2.6.2 Services offert par la couche MAC .................................................................. 24<br />
2.6.3 Structures des trames MAC.............................................................................. 25<br />
2.6.4 Protocoles MAC ............................................................................................... 29<br />
2.6.4.1 CSMA/CA.................................................................................................... 30<br />
2.6.4.2 RTS/CTS ...................................................................................................... 32<br />
2.6.4.3 Polling .......................................................................................................... 34<br />
2.6.5 Fragmentation.................................................................................................. 35<br />
2.6.6 Synchronisation................................................................................................ 36<br />
2.6.7 Power-Saving Mode ......................................................................................... 36<br />
2.7 COUCHE PHYSIQUE.................................................................................................... 38<br />
2.7.1 Services offerts par la couche physique ........................................................... 38<br />
2.7.2 DSSS................................................................................................................. 40<br />
2.7.3 FHSS................................................................................................................. 45<br />
2.7.4 Infrarouge (IR) ................................................................................................. 46<br />
3 BLUETOOTH ................................................................................................................ 48<br />
3.1 INTRODUCTION.......................................................................................................... 49<br />
3.2 L'ARCHITECTURE DU PROTOCOLE.............................................................................. 50<br />
3.2.1 Accès au canal de transmission ....................................................................... 51<br />
3.3 CLASSE DE PUISSANCE .............................................................................................. 53<br />
4
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3.4 BASEBAND................................................................................................................ 54<br />
3.4.1 Architecture...................................................................................................... 54<br />
3.4.1.1 Maître <strong>et</strong> Esclave.......................................................................................... 54<br />
3.4.1.2 Timing .......................................................................................................... 54<br />
3.4.1.3 Picon<strong>et</strong>s ........................................................................................................ 54<br />
3.4.1.4 Adresses ....................................................................................................... 56<br />
3.4.2 Protection des données..................................................................................... 57<br />
3.4.2.1 FEC 1/3 ........................................................................................................ 57<br />
3.4.2.2 FEC 2/3 ........................................................................................................ 57<br />
3.4.2.3 ARQ ............................................................................................................. 58<br />
3.4.3 Taille des paqu<strong>et</strong>s............................................................................................. 58<br />
3.4.4 Liaison.............................................................................................................. 59<br />
3.4.4.1 Liaison SCO ................................................................................................. 59<br />
3.4.4.2 Liaison ACL................................................................................................. 59<br />
3.4.5 Structure des paqu<strong>et</strong>s ....................................................................................... 59<br />
3.4.6 Access code ...................................................................................................... 60<br />
3.4.6.1 Access code types......................................................................................... 60<br />
3.4.6.2 Preamble....................................................................................................... 61<br />
3.4.6.3 Sync Word.................................................................................................... 61<br />
3.4.6.4 Trailer........................................................................................................... 61<br />
3.4.6.5 Entête de paqu<strong>et</strong> ........................................................................................... 61<br />
3.4.7 Type de paqu<strong>et</strong> ................................................................................................. 63<br />
3.4.7.1 Paqu<strong>et</strong> ID...................................................................................................... 64<br />
3.4.7.2 Paqu<strong>et</strong> NULL ............................................................................................... 64<br />
3.4.7.3 Paqu<strong>et</strong> POLL................................................................................................ 64<br />
3.4.7.4 Paqu<strong>et</strong> FHS................................................................................................... 64<br />
3.4.7.5 Paqu<strong>et</strong> DM1.................................................................................................. 66<br />
3.4.7.6 Paqu<strong>et</strong> HV1 .................................................................................................. 66<br />
3.4.7.7 Paqu<strong>et</strong> HV2 .................................................................................................. 67<br />
3.4.7.8 Paqu<strong>et</strong> HV3 .................................................................................................. 67<br />
3.4.7.9 Paqu<strong>et</strong> DV .................................................................................................... 67<br />
3.4.7.10 Paqu<strong>et</strong> DH1 .............................................................................................. 67<br />
3.4.7.11 Paqu<strong>et</strong> DM3.............................................................................................. 67<br />
3.4.7.12 Paqu<strong>et</strong> DH3 .............................................................................................. 68<br />
3.4.7.13 Paqu<strong>et</strong> DM5.............................................................................................. 68<br />
3.4.7.14 Paqu<strong>et</strong> DH5 .............................................................................................. 68<br />
3.4.7.15 Paqu<strong>et</strong> AUX ............................................................................................. 68<br />
5
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3.4.8 Entête de cargaison.......................................................................................... 69<br />
3.4.9 Canaux logique ................................................................................................ 69<br />
3.5 LINK CONTROLLER.................................................................................................... 71<br />
3.5.1 Etat du Link Controller .................................................................................... 71<br />
3.5.2 Procédure Inquiry ............................................................................................ 72<br />
3.5.2.1 Sous-état Inquiry .......................................................................................... 72<br />
3.5.2.2 Sous-état Inquiry Scan ................................................................................. 74<br />
3.5.2.3 Sous-état Inquiry Response.......................................................................... 75<br />
3.5.3 Procédure Page................................................................................................ 75<br />
3.5.3.1 Sous-état Page .............................................................................................. 75<br />
3.5.3.2 Sous-état Page scan ...................................................................................... 76<br />
3.5.3.3 Sous-état Page response ............................................................................... 76<br />
4 COEXISTENCE............................................................................................................. 78<br />
4.1 PROBLEMATIQUE....................................................................................................... 79<br />
4.2 COMPORTEMENT DES EQUIPEMENTS.......................................................................... 81<br />
4.3 PREVISIONS ET STATISTIQUES.................................................................................... 82<br />
4.3.1 Calcul de la probabilité d’interférences .......................................................... 82<br />
4.3.2 Influence du comportement des dispositifs Blu<strong>et</strong>ooth...................................... 85<br />
4.3.3 Rapport <strong>entre</strong> la probabilité d’interférences <strong>et</strong> les performances de <strong>WLAN</strong>... 88<br />
4.4 EVALUATION DES PERFORMANCES REELLES DE <strong>WLAN</strong>............................................ 89<br />
5 MESURES, SIMULATIONS ET SOLUTIONS EXISTANTES ............................... 94<br />
5.1 MESURES ET RESULTATS ........................................................................................... 95<br />
5.1.1 Simulations....................................................................................................... 95<br />
5.1.2 Mesures ............................................................................................................ 96<br />
5.2 SOLUTIONS................................................................................................................ 97<br />
5.2.1 Adaptive Frequency Hopping (AFH) ............................................................... 98<br />
5.2.2 <strong>Dr</strong>iver-level Switching.................................................................................... 100<br />
5.2.3 MAC-level Switching...................................................................................... 101<br />
5.2.4 Manual Switching........................................................................................... 101<br />
6 MODELE THEORIQUE ............................................................................................ 103<br />
6.1 OBJECTIF................................................................................................................. 104<br />
6.2 MODELE DE PROPAGATION DES ONDES ELECTROMAGNETIQUES.............................. 105<br />
6.2.1 Généralités ..................................................................................................... 105<br />
6.2.2 Hypothèse n°1 : Caractéristiques des antennes............................................. 106<br />
6.2.3 Hypothèse n°2 : Longueur d’onde ................................................................. 109<br />
6
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.2.4 Hypothèse n°3 : Conditions atmosphériques ................................................. 110<br />
6.2.5 Hypothèse n°4 : Mobilité................................................................................ 110<br />
6.2.6 Hypothèse n°5 : Réflexions ............................................................................ 111<br />
6.2.7 Résumé des hypothèses................................................................................... 112<br />
6.2.8 Description du modèle de propagation.......................................................... 113<br />
6.3 MODELE D’INTERFERENCE ...................................................................................... 114<br />
6.3.1 Description générale du modèle .................................................................... 114<br />
6.3.2 Hypothèses ..................................................................................................... 115<br />
6.3.3 Description de la simulation .......................................................................... 116<br />
6.3.3.1 Description générale................................................................................... 116<br />
6.3.3.2 <strong>WLAN</strong>........................................................................................................ 116<br />
6.3.3.3 Canal <strong>et</strong> interférences................................................................................. 116<br />
6.3.3.4 Communications Blu<strong>et</strong>ooth........................................................................ 117<br />
6.3.3.5 Traitement des résultats.............................................................................. 119<br />
6.3.3.6 Mode d’emploi ........................................................................................... 119<br />
6.3.4 Résultats de la simulation .............................................................................. 122<br />
6.3.4.1 Transmission <strong>WLAN</strong> perturbée par un ém<strong>et</strong>teur Blu<strong>et</strong>ooth ...................... 122<br />
6.3.4.2 Influence de la dimension des trames ........................................................ 126<br />
6.3.4.3 Influence du débit....................................................................................... 127<br />
6.3.4.4 Comportement en présence de plusieurs dispositifs Blu<strong>et</strong>ooth.................. 128<br />
6.4 MODELE MATHEMATIQUE GENERAL DU DEBIT ........................................................ 129<br />
6.4.1 Calcul du débit réel........................................................................................ 129<br />
6.4.2 Sans codage des bits....................................................................................... 130<br />
6.4.3 Avec un codage FEC (Forwar Error Correction) 1/3 ................................... 130<br />
6.4.4 Calcule du débit réel connaissant le probabilité de transmission d’un bit<br />
logique (pour FEC 1/3 <strong>et</strong> sans codage) ......................................................................... 131<br />
6.4.5 Avec un codage FEC 2/3 :.............................................................................. 133<br />
6.5 DEBIT REEL DES PAQUETS BLUETOOTH ................................................................... 136<br />
6.5.1 Code d’accès .................................................................................................. 136<br />
6.5.2 Entête.............................................................................................................. 136<br />
6.5.3 Cargaison par type......................................................................................... 137<br />
6.5.3.1 DH1 ............................................................................................................ 137<br />
6.5.3.2 DH3 ............................................................................................................ 139<br />
6.5.3.3 DH5 ............................................................................................................ 140<br />
6.5.3.4 DM1 ........................................................................................................... 142<br />
6.5.3.5 DM3 ........................................................................................................... 143<br />
6.5.3.6 DM5 ........................................................................................................... 144<br />
7
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.5.4 Simulation en JAVA........................................................................................ 146<br />
6.5.5 Conclusion débit Blu<strong>et</strong>ooth ............................................................................ 147<br />
6.6 DEBIT THEORIQUE DE <strong>WLAN</strong> ................................................................................. 148<br />
6.6.1 Préambule PLCP............................................................................................ 148<br />
6.6.2 Entête PLCP................................................................................................... 149<br />
6.6.3 Payload de PLCP........................................................................................... 149<br />
6.6.4 Débit réel de <strong>WLAN</strong> ....................................................................................... 150<br />
6.6.5 Influence de la taille des paqu<strong>et</strong>s ................................................................... 150<br />
7 MESURES..................................................................................................................... 153<br />
7.1 CONDITIONS DE MESURES........................................................................................ 154<br />
7.1.1 Environnement ............................................................................................... 154<br />
7.1.2 Equipement..................................................................................................... 156<br />
7.2 MESURES................................................................................................................. 157<br />
7.2.1 Mesures en plein air....................................................................................... 157<br />
7.2.2 Mesures en chambre anéchoïque ................................................................... 157<br />
7.2.2.1 Conditions de mesures ............................................................................... 157<br />
7.2.2.2 Mesure du spectre de Blu<strong>et</strong>ooth................................................................. 158<br />
7.2.2.3 Mesure des performances de <strong>WLAN</strong> ......................................................... 160<br />
7.3 ANALYSE DES RESULTATS DE MESURE .................................................................... 161<br />
7.3.1 Qualité de la mesure ...................................................................................... 161<br />
7.3.2 Imprécisions au niveau PLCP........................................................................ 161<br />
7.4 REMARQUES CONCERNANT LES TECHNIQUES DE MESURES...................................... 163<br />
8 ANALYSES ET SOLUTIONS.................................................................................... 164<br />
8.1 COEXISTENCE ENTRE <strong>802.11</strong>B ET BLUETOOTH........................................................ 165<br />
8.1.1 Constats.......................................................................................................... 165<br />
8.1.2 Etat des trames erronées <strong>et</strong> méthodes d’accès au canal................................ 165<br />
8.1.3 Dimensionnement des trames......................................................................... 166<br />
8.1.4 Robustesse des techniques de modulation...................................................... 167<br />
8.1.5 Utilisation de Blu<strong>et</strong>ooth ................................................................................. 167<br />
8.1.5.1 Type de dispositif....................................................................................... 167<br />
8.1.5.2 Quantité de dispositif ................................................................................. 168<br />
8.1.6 Eff<strong>et</strong> des émissions parasites de Blu<strong>et</strong>ooth .................................................... 169<br />
8.1.7 RINEA............................................................................................................. 173<br />
8.1.7.1 Introduction ................................................................................................ 173<br />
8.1.7.2 Algorithme ................................................................................................. 173<br />
8
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
8.1.7.3 Débit réel théorique.................................................................................... 174<br />
8.1.7.4 Simulation .................................................................................................. 180<br />
8.1.7.5 Ressource nécessaire.................................................................................. 181<br />
8.1.7.6 Algorithme informatique............................................................................ 182<br />
8.1.7.7 Mesures ...................................................................................................... 184<br />
8.2 CHANGEMENT DE TECHNOLOGIE ? .......................................................................... 185<br />
8.2.1 Technologies <strong>et</strong> bandes de fréquences ........................................................... 185<br />
8.2.2 Quels réseaux choisir ?.................................................................................. 185<br />
8.2.2.1 <strong>802.11</strong>a ....................................................................................................... 186<br />
8.2.2.2 <strong>802.11</strong>g....................................................................................................... 188<br />
8.2.2.3 HiperLAN................................................................................................... 188<br />
8.2.2.4 Home RF .................................................................................................... 189<br />
9 INTERFERENCES ENTRE RESEAUX <strong>WLAN</strong>...................................................... 191<br />
9.1 DESCRIPTION DU PROBLEME.................................................................................... 192<br />
9.2 INTERFERENCES ENTRE RESEAUX UTILISANT DES CANAUX DIFFERENTS.................. 192<br />
9.2.1 Description..................................................................................................... 192<br />
9.2.2 Simulation....................................................................................................... 193<br />
9.2.3 Analyse des résultats ...................................................................................... 196<br />
9.3 INTERFERENCE ENTRE RESEAUX UTILISANT LE MEME CANAL.................................. 197<br />
9.4 CONCLUSION........................................................................................................... 198<br />
10 DOCUMENTATION LOGICIEL.......................................................................... 200<br />
10.1 LAN EVALUATION.................................................................................................. 201<br />
10.2 NETWORK STUMBLER ............................................................................................. 202<br />
10.3 PRISM BENCHMARK PRO....................................................................................... 203<br />
10.4 AIROPEEK................................................................................................................ 204<br />
10.5 BLUELET ................................................................................................................. 206<br />
11 CONCLUSIONS....................................................................................................... 208<br />
12 REMERCIEMENTS................................................................................................ 211<br />
13 BIBLIOGRAPHIE................................................................................................... 214<br />
9
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
10
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
1 Introduction<br />
11
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
1.1 Motivation<br />
Les technologies sans-fils ont une importance grandissante dans le monde de la<br />
téléinformatique. Il est maintenant possible de transm<strong>et</strong>tre des données <strong>entre</strong><br />
équipements informatiques sans le moindre câblage. L’absence de câblage perm<strong>et</strong> de<br />
réduire les coûts d’installation d’un réseau, surtout lorsque les locaux sont difficiles à<br />
câblés. De plus, le sans-fil offre une mobilité accrue. Il n’est plus nécessaire de refaire<br />
entièrement le câblage lors d’un déménagement ou d’un réaménagement. L’utilisateur<br />
peut se déplacer tout en restant connecté au réseau.<br />
Figure 1 : Complémentarité <strong>entre</strong> Blu<strong>et</strong>ooth <strong>et</strong> Wireless LAN (source : Mobilian, Gartner)<br />
Depuis la fin du siècle passé, plusieurs technologies ont émergé pour les besoins de<br />
l’informatique (Wireless LAN, HiperLAN, Blu<strong>et</strong>ooth, Home RF, …). Actuellement<br />
deux normes ont très n<strong>et</strong>tement pris les devants ; Wireless LAN <strong>802.11</strong>b <strong>et</strong> Blu<strong>et</strong>ooth.<br />
<strong>WLAN</strong> <strong>802.11</strong>b utilise un protocole proche de celui d’Ethern<strong>et</strong>. Avec un débit<br />
pouvant aller jusqu’à 11Mbps <strong>et</strong> une portée supérieure à 100m, <strong>WLAN</strong> est destiné à la<br />
réalisation de réseaux locaux. Blu<strong>et</strong>ooth a été conçu pour un autre type d’application.<br />
Contrairement à <strong>WLAN</strong>, les communications avec Blu<strong>et</strong>ooth sont basées sur le<br />
modèle maître-esclave. Le débit maximal est de 1Mbps pour une portée ne dépassant<br />
pas 10m. Les deux normes sont donc complémentaires, l’une servant à la réalisation<br />
de réseaux informatiques <strong>et</strong> la seconde, moins coûteuse à la fabrication, peut être<br />
intégrée à une souris sans-fil, à un téléphone portable ou encore à un agenda<br />
12
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
électronique. Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong> ont un rapport performances-prix différent, les<br />
applications auxquelles ils sont destinés sont donc différentes.<br />
La complémentarité <strong>entre</strong> les technologies Blu<strong>et</strong>ooth <strong>et</strong> Wireless LAN fait qu’elles se<br />
r<strong>et</strong>rouvent souvent contraintes de travailler dans le même environnement. Cela ne<br />
poserait aucun problèmes si les deux normes ne transm<strong>et</strong>tait pas dans la même bande<br />
de fréquences. C<strong>et</strong>te bande de fréquence, appelée ISM (Industrial, Scientific and<br />
Medical), est comprise <strong>entre</strong> 2,4 <strong>et</strong> 2,4835GHz. Les dispositifs Blu<strong>et</strong>ooth <strong>et</strong> Wireless<br />
LAN <strong>802.11</strong>b interfèrent lorsqu’ils communiquent simultanément. Malgré l’utilisation<br />
d’une modulation à spectre étalé, les interférences pénalisent le débit des dispositifs.<br />
Les détériorations que subit une transmission peuvent dans certains cas nuire<br />
fortement à la qualité de service d’une application, <strong>et</strong> même la rendre inutilisable.<br />
Paradoxalement, le problème posé par la coexistence <strong>entre</strong> Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong> ne<br />
semble par freiner l’expansions de ces nouvelles technologies. Mais il est cependant<br />
nécessaire de quantifier les dégradations <strong>et</strong> d’apporter des solutions en vue de la<br />
cohabitation <strong>entre</strong> les deux normes. L’enjeu est important, car la quantité <strong>et</strong> la<br />
diversité des appareils ém<strong>et</strong>tant dans la bande de fréquence ISM ira grandissante.<br />
Parallèlement, si aucun effort n’est fait pour améliorer la coexistence <strong>entre</strong> les<br />
différentes normes, les baisses de performances risquent de rendre impopulaire une<br />
technologie qui s’annonce très intéressante tant au niveau des nouvelles possibilités<br />
offertes aux utilisateurs qu’aux nouveaux c<strong>entre</strong> de profits qu’elle peut amener.<br />
1.2 Objectifs<br />
Ce document est une étude de la coexistence <strong>entre</strong> Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong>. Le but de<br />
c<strong>et</strong>te étude est de fournir un ensemble de modèles théoriques <strong>et</strong> de prescriptions<br />
perm<strong>et</strong>tant d’optimiser les performances des réseaux informatiques sans-fils.<br />
La première partie de ce document traite des deux normes concernées par c<strong>et</strong>te étude.<br />
Il s’agit de disposer des informations nécessaires à la bonne compréhension des<br />
problèmes de coexistence. Une attention particulière est apportée aux études déjà<br />
publiées sur le suj<strong>et</strong> ainsi qu’aux solutions apportées par certains constructeurs. C<strong>et</strong>te<br />
collection d’information est utile dans la mesure ou elle perm<strong>et</strong> d’orienter nos<br />
recherches <strong>et</strong> d’en vérifier la concordance. Il est ainsi possible de comparer les<br />
résultats obtenus dans le cadre de c<strong>et</strong>te étude avec ceux que prom<strong>et</strong>tent les fabricants.<br />
13
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Les modèles théoriques reflètent le comportement des dispositifs en fonction d’un<br />
certains nombres de paramètres 1 . Ainsi il est possible de dimensionner un réseau ou<br />
d’évaluer les performances d’une application sans avoir à réaliser physiquement la<br />
solution. Pour vérifier l’exactitude <strong>et</strong> les limites des modèles proposés, les résultats<br />
d’un ensemble de mesures sont inclues dans ce document.<br />
1 Distance <strong>entre</strong> dispositifs, puissance des ém<strong>et</strong>teurs, environnement, …<br />
14
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
15
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
2 <strong>WLAN</strong><br />
16
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
2.1 Introduction<br />
C<strong>et</strong>te présentation de la norme <strong>WLAN</strong> <strong>802.11</strong> insiste surtout sur les aspects<br />
concernant l’étude de la coexistence <strong>entre</strong> Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong> <strong>802.11</strong>b. Certaines<br />
particularités de la norme sont donc volontairement traitées en surface.<br />
La norme <strong>WLAN</strong> <strong>802.11</strong> à été mise en place afin perm<strong>et</strong>tre une connexion sans-fils<br />
automatique à un réseau informatique. Le but étant d’obtenir l’équivalent des réseaux<br />
LAN classiques, avec en plus les avantages offerts par le sans-fils (mobilité,<br />
deploiement rapide, …). <strong>802.11</strong> regroupe plusieurs variantes de la norme:<br />
• <strong>802.11</strong>a<br />
C<strong>et</strong>te norme, définissant la couche physique de <strong>802.11</strong>, offre un débit<br />
pouvant aller jusqu’à 54 Mbps <strong>et</strong> travaille à 5 GHz. Contrairement à<br />
<strong>802.11</strong>b <strong>et</strong> <strong>802.11</strong>g, <strong>802.11</strong>a n’intéfère pas avec Blu<strong>et</strong>ooth. Blu<strong>et</strong>ooth<br />
travaillant à 2,4 GHz.<br />
• <strong>802.11</strong>b<br />
<strong>802.11</strong>b utilise la bande ISM à 2,4 GHz. Le débit maximum imposé par<br />
la norme est de 11 Mbps. C’est actuellement la norme la plus répandue<br />
dans le domaine des réseaux informatiques sans-fils. Wi-Fi 1 est une autre<br />
appellation pour <strong>802.11</strong>b.<br />
• <strong>802.11</strong>c<br />
C<strong>et</strong>te norme définit le fonctionnement des points d’accès (AP).<br />
• <strong>802.11</strong>d<br />
<strong>802.11</strong>d s’occupe de l’interopérabilité <strong>entre</strong> équipements.<br />
• <strong>802.11</strong>e<br />
Le développement actuel des réseaux informatiques a fait apparaître de<br />
nouvelles applications demandant une meilleur qualité des transmissions.<br />
<strong>802.11</strong>e doit perm<strong>et</strong>tre d’améliorer la QoS (Qualité of Service) afin<br />
d’obtenir des performances optimums des applications utilisant par<br />
exemple la transmission de la voix ou de la vidéo. Les modifications<br />
1 Voir section 2.2<br />
17
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
apportées aux protocoles existants portent essentiellement sur la couche<br />
MAC.<br />
• <strong>802.11</strong>f<br />
Le but de <strong>802.11</strong>f <strong>et</strong> de spécifier les fonctions de roaming. Ainsi un<br />
utilisateur peut se déplacer d’une zone couverte par un AP à une zone<br />
couverte par un autre AP sans interruption de la communication, <strong>et</strong> cela<br />
avec des AP provenant de fournisseurs différents.<br />
• <strong>802.11</strong>g<br />
<strong>802.11</strong>g n’est pas encore achevée à l’heure actuelle. Son but est d’offrir<br />
des débits plus importants que ceux de <strong>802.11</strong>b tout en restant à<br />
2,4GHz. C<strong>et</strong>te norme devra, comme <strong>802.11</strong>b, coexister avec Blu<strong>et</strong>ooth.<br />
• <strong>802.11</strong>h<br />
<strong>802.11</strong>h est une extension de <strong>802.11</strong>a. Elle est mieux adaptée à la<br />
réglementation européenne, car elle offre une sélection dynamique du<br />
canal (DCS) <strong>et</strong> un contrôle de la puissance d’émission (TPC).<br />
Comme <strong>WLAN</strong> <strong>802.11</strong> fonctionne dans l’espace aérien, elle se r<strong>et</strong>rouve confrontée<br />
aux interférences. Ces interférences produisent un taux d’erreurs particulièrement<br />
élevé en comparaison avec les transmissions par câble. C<strong>et</strong>te particularité a été prise en<br />
compte dans la spécification de la norme, mais les performances de <strong>802.11</strong> restent<br />
fortement liées à l’environnement dans lequel évoluent les dispositifs.<br />
2.2 Wi-Fi<br />
Wi-Fi (Wireless Fidelity) est une certification garantissant l’interopérabilité <strong>entre</strong><br />
équipements. Elle est le résultat du travail d’une organisation appelée WECA<br />
(Wireless Ethern<strong>et</strong> Certification Alliannce). Née en 1999, c<strong>et</strong>te organisation regroupe<br />
40 des plus grands fournisseurs d’équipements informatiques. Le but de WECA est de<br />
promouvoir Wi-Fi comme la seule véritable norme pour les réseaux informatiques<br />
locaux sans-fils. Chaque constructeur désirant vendre un équipement Wi-Fi doit<br />
d’abord le faire certifier. Pour obtenir la certification Wi-Fi, l’équipement concerné<br />
doit répondre à la norme IEEE <strong>802.11</strong>b. La tendance actuelle veut que le nom Wi-Fi<br />
18
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
remplace progressivement celui de <strong>802.11</strong>b lorsque l’on parle de <strong>WLAN</strong>, un peu à la<br />
manière d’Ethern<strong>et</strong> qui a remplacé l’appelation 802.3 de l’IEEE.<br />
2.3 Architecture des réseaux <strong>802.11</strong><br />
Un réseau <strong>WLAN</strong> <strong>802.11</strong> est organisé de manière hiérarchique (voir la figure de la<br />
page suivante). Un ensemble de stations (STA) communiquent directement <strong>entre</strong> elle<br />
au sein d’un BSS (Basic Service S<strong>et</strong>). La dimension d’un BSS est limitée par la portée<br />
des ém<strong>et</strong>teurs des STA. L’extension d’un BSS ou son interconnexion avec un autre<br />
BSS nécessite l’utilisation d’un point d’accès (AP). Un BSS désirant être connecter à<br />
d’autres BSS doit d’abord être connecter au DS 1 (Distribution System) par<br />
l’intermédiaire de son AP. Lorsque plusieurs BSS sont interconnectés, ils constituent<br />
un ESS (Extended Service S<strong>et</strong>). L’interconnexion d’un BSS ou d’un ESS avec un autre<br />
type de réseau passe par un portail (portal), la plupart du temps un AP est dédié à c<strong>et</strong>te<br />
fonction. Le cas le plus courant est l’interconnexion d’un <strong>WLAN</strong> avec un LAN.<br />
Lorsqu’un BSS utilise un AP, on parle de BSS basé sur infrastructure.<br />
Un BSS a la possibilité de travailler indépendamment. C’est-à-dire qu’il ne dispose pas<br />
d’AP <strong>et</strong> que les STA ne communiquent donc qu’avec des STA appartenant au même<br />
BSS. Ce type de réseau est appelé réseau ad hoc ou IBSS (Independant Basic Service<br />
S<strong>et</strong>).<br />
1 Le DS peut être un LAN, un réseau sans-fils ou tout autre type de réseau. Il faut bien entendu<br />
disposer d’un AP perm<strong>et</strong>tant de s’y connecter.<br />
19
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Figure 2 : Eléments de l'architecture <strong>802.11</strong><br />
STA : Station<br />
AP : Access Point<br />
SS : Station Service<br />
DSS : Distribution System Service<br />
BSS : Basic Service S<strong>et</strong><br />
ESS : Extended Service S<strong>et</strong><br />
DS : Distribution System<br />
20
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
2.4 Services des réseaux <strong>802.11</strong><br />
Les services offerts par <strong>802.11</strong> sont séparé en deux catégories : Station Service (SS) <strong>et</strong><br />
Distribution System Service (DSS).<br />
• Station Service comprend les services suivants :<br />
Authentification, désauthentification, sécurité (privacy), livraison des<br />
MSDU<br />
• Distribution System Service :<br />
Association, désassociation, distribution, intégration, réassociation<br />
2.4.1 Station Serivce (SS)<br />
Authentification, désauthentification<br />
L’authentification perm<strong>et</strong> au stations d’un BSS d’échanger leur identité. <strong>802.11</strong> ne<br />
propose qu’un seul type d’authentification au niveau liaison, les fonctions plus<br />
avancées ne sont pas traitées dans le cadre de la norme. La désauthenfication consiste<br />
simplement à effacer de la mémoire une station authentifiée.<br />
Sécurité<br />
<strong>802.11</strong> spécifie un mécanisme pour protéger les informations véhiculées sur le réseau.<br />
Ce mécanisme, appelé WEP 1 , est optionnel.<br />
La livraison des MSDU (MAC Service Data Unit), qui constitue aussi un service ss, est<br />
traitée ultérieurement dans ce document (voir section 2.6).<br />
2.4.2 Distribution System Service (DSS)<br />
Les DSS servent à transm<strong>et</strong>tre des message dans le DS (Distribution System), ce qui<br />
perm<strong>et</strong> en autre d’assurer la mobilité (roaming). <strong>802.11</strong> définit trois types de mobilité :<br />
1 WEP : Wired Equivalent Privacy<br />
21
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
• No-transition, lorsque les stations sont immobiles ou ne se déplacent qu’à<br />
l’intérieur d’un BSS.<br />
• BSS-transition, losque les stations changent de BSS mais restent à<br />
l’intérieur du même ESS.<br />
• ESS-transition, Lorsqu’une stations passe d’un BSS d’un ESS à un autre<br />
BSS d’un autre ESS. <strong>802.11</strong> ne spécifie pas le changement de ESS, c<strong>et</strong>te<br />
opération entraîrera donc une interruption de la communication.<br />
Pour assurer la mobilité des stations, <strong>802.11</strong> a besoin des services appelés association<br />
services. Il est important de garder en mémoire qu’une association n’est possible que si<br />
le BSS dispose d’un AP. Un réseau ad hoc ne génère aucune association.<br />
Association<br />
Ce service perm<strong>et</strong> a un AP de connaître les stations contenues dans son BSS. Une<br />
station arrivant dans le BSS d’un AP doit s’identifier auprès de c<strong>et</strong>te AP. Il est<br />
important de relever qu’une station ne peut être associée qu’a un seul AP à la fois.<br />
C<strong>et</strong>te particularité facilite le routage des MSDU dans le DS. Bien qu’une station ne soit<br />
associée qu’à un seul AP, elle peut, dans la mesure ou le nombre d’AP visible est<br />
supérieur à un, choisir 1 <strong>entre</strong> plusieurs AP.<br />
Désassiociation<br />
Lorsqu’une station quitte un BSS, l’association <strong>entre</strong> AP <strong>et</strong> STA est supprimée. C<strong>et</strong>te<br />
opération est appelée désassociation.<br />
Réassiociation<br />
Lorsqu’une station change de BSS, l’association est transmise d’un AP à l’autre par le<br />
DS. La réassociation perm<strong>et</strong> le roaming <strong>entre</strong> BSS. Pour améliorer la rapidité du<br />
changement de BSS, une pré-authentification est possible.<br />
1 C<strong>et</strong>te opération est effectuée par scanning.<br />
22
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
2.5 Structure du protocole<br />
Figure 3 : Structure du protocole <strong>802.11</strong><br />
La figure ci-dessus présente les couches OSI spécifiées par la norme <strong>802.11</strong>. La<br />
couche physique se divise en deux sous-couches ; PLCP (Physical Layer Convergence<br />
Protocol) <strong>et</strong> PMD (Physical Medium Dependent). La couche PMD s’occupe du<br />
codage <strong>et</strong> de la modulation des signaux, alors que la couche PLCP perm<strong>et</strong> à la couche<br />
MAC de travailler indépendamment de la technologie utilisée pour la transmission. Le<br />
fonctionnement de chacune de ces couches est décrite plus précisément dans la suite<br />
de ce document.<br />
2.6 Couche MAC<br />
2.6.1 Adresses<br />
La norme <strong>802.11</strong> utilise des adresses de 48 bits. Pour les besoins du réseau sans-fils<br />
cinq types d’adresses ont été définis :<br />
• BSS Identifier (BSSID)<br />
Le BSSID perm<strong>et</strong> de différencier chaque BSS. C<strong>et</strong>te adresse peut être de<br />
deux natures différentes. Si le BSS possède un point d’accès (AP), alors<br />
c’est l’adresse MAC de l’AP qui est choisie comme BSSID. Dans le cas<br />
d’un réseau ad hoc, l’adresse est formée à partir d’un nombre aléatoire.<br />
23
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
• Destination Address (DA)<br />
Adresse MAC du destinataire d’une MSDU.<br />
• Source Address (SA)<br />
Adresse MAC de l’ém<strong>et</strong>teur d’une MSDU.<br />
• Receiver Address (RA)<br />
Adresse MAC d’un équipements intermédiaire par lequel va transiter une<br />
MSDU.<br />
• Transmitter Address (TA)<br />
Adresse MAC de la dernière station ou équipement par lequel à transité<br />
une MSDU.<br />
2.6.2 Services offert par la couche MAC<br />
La couche LLC 1 dispose des primitives suivantes : MA-UNITDATA.request, MA-<br />
UNITDATA.indication <strong>et</strong> MA-UNITDATA-STATUS.indication. Les primitives de la<br />
couche MAC disposent des paramètres suivant :<br />
Source address (SA)<br />
Adresse de l’ém<strong>et</strong>teur.<br />
Destination address(DA)<br />
Adresse du destinataire.<br />
Routing Information<br />
Doit rester nul dans le cas de <strong>802.11</strong>.<br />
Data<br />
C<strong>et</strong>te MSDU est transportée sans aucune modification <strong>entre</strong> les couches LLC de<br />
l’ém<strong>et</strong>teur <strong>et</strong> du destinataire. La taille maximum de la MSDU ne doit pas excéder<br />
2312 oct<strong>et</strong>s.<br />
1 La couche LLC est directement au-dessus de la couche MAC. Elle accède aux services offerts par la<br />
couche MAC par le biai du MAC SAP.<br />
24
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Priority<br />
Deux niveaux de priorité sont disponibles : Contention <strong>et</strong> Contention-Free.<br />
Service class<br />
Il existe deux types de classes : Recordable Multicast <strong>et</strong> Strictly Ordrered.<br />
Reception status<br />
Perm<strong>et</strong> d’obtenir le résultat de la réception.<br />
Transmission status<br />
Perm<strong>et</strong> d’otenir de l’information sur la transmission.<br />
2.6.3 Structures des trames MAC<br />
La figure ci-dessous montre la structure générale d’une trame MAC dans <strong>802.11</strong>. Le<br />
champ Frame Control est traité en détail dans la seconde figure car il perm<strong>et</strong> de gérer<br />
plusieurs paramètres lors de la communication.<br />
Figure 4 : Format d’une trame MAC (source : [<strong>WLAN</strong>99])<br />
Champ Frame Control<br />
Figure 5 : Format du champs Frame Control (source : [<strong>WLAN</strong>99])<br />
25
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Protocole Version indique la version de la norme (<strong>802.11</strong>a, <strong>802.11</strong>b, …)<br />
Type <strong>et</strong> Subtype<br />
Les champs type <strong>et</strong> sous-type perm<strong>et</strong>tent d’identifier la fonction de la trame, il existe<br />
trois types différents ; control, data <strong>et</strong> management. Les sous-types perm<strong>et</strong>tent de<br />
préciser plus encore la fonction de la trame.<br />
Tableau 1 : Combinaisons <strong>entre</strong> Type <strong>et</strong> Subtype (source : [<strong>WLAN</strong>99])<br />
26
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
To DS / From DS<br />
Lorsque le To DS est à 1, cela signifie que la trame est destinée au DS. From DS est à<br />
1 lorsque la trame provient du DS. La figure ci-dessous m<strong>et</strong> en évidence les différentes<br />
possibilités de combiner les bit To DS <strong>et</strong> From DS.<br />
Tableau 2 : Valeurs possibles de To DS <strong>et</strong> From DS (source : [<strong>WLAN</strong>99])<br />
More Frag est à 1 si il y a encore au moins un fragment qui suit.<br />
R<strong>et</strong>ry est à 1 si la trame est une r<strong>et</strong>ransmission d’une trame déjà envoyée<br />
précédemment. C<strong>et</strong>te information est très utile, elle perm<strong>et</strong> à la station réceptrice de<br />
supprimer les duplicatas.<br />
Pwr Mgt<br />
Le bit Pwr Mgt est à 1, si la station qui a émit la trame va passer en mode Doze. Une<br />
trame provenant d’un AP ne peut avoir le bit Pwr Mgt à 1.<br />
More Date<br />
Ce bit est utilisé par l’AP pour indiquer à une station qu’il lui reste au moins une trame<br />
en tampon qui lui est destinée à c<strong>et</strong>te station.<br />
WEP<br />
Si le bit WEP est à 1, cela signifie que le corp de la trame (Frame Body) est crypté.<br />
Order est à 1, si le fragment utilise la classe de service StrictlyOrdered.<br />
27
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Les champs décrits à la page précédente appartiennent au champ Frame Control<br />
d’une trame MAC. La partie suivante traite des autres champs contenu dans la<br />
trame MAC.<br />
Duration/ID<br />
Ce champ remplit deux fonctions importantes :<br />
• Il peut contenir l’identificateur d’association (AID) lors de l’envoi d’une<br />
trame PS-Poll 1 .<br />
• Perm<strong>et</strong> de transm<strong>et</strong>tre les durées des réservations (NAV) dans la méthode<br />
RTS/CTS.<br />
Tableau 3 : Codage du champ Duration/ID (source : [<strong>WLAN</strong>99])<br />
Address 1 à 4<br />
Une trame MAC peut contenir quatre adresses parmi les cinq définies par la norme ;<br />
BSSID, SA (Source Address), DA (Destination Address), TA (Transmitter Address) <strong>et</strong><br />
RA (Receiver Address). Le tableau suivant montre les différentes combinaisons<br />
possibles des adresses dans une trame MAC.<br />
Tableau 4 : Contenu des champs adresses (source : [<strong>WLAN</strong>99])<br />
1 Voir section sur Power Saving Control<br />
28
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Sequence Control perm<strong>et</strong> de contrôler le séquencement des fragements. Pour cela le<br />
champ Sequence Control est divisé en deux sous-champs ; Fragment Number <strong>et</strong><br />
Sequence Number. Fragment Number indique sur 4 bits le numéro du fragment de la<br />
MSDU. A l’envoi du premier fragment d’une MSDU, le Fragment Number est<br />
initialisé à zéro, ensuite il est incrémenté à chaque nouveau fragment. Le Sequence<br />
Number (12 bits) indique quant à lui le numéro du fragment par rapport à l’ensemble<br />
de la communication.<br />
Frame Body contient les données, la taille des données doit être comprise en 0 <strong>et</strong><br />
2312 oct<strong>et</strong>s.<br />
FCS détecte <strong>et</strong> contrôle les erreurs au moyen d’un CRC de 32 bits.<br />
2.6.4 Protocoles MAC<br />
<strong>802.11</strong> dispose de trois méthodes pour accéder au canal. Ces trois méthodes se<br />
nomment CSMA/CA 1 , RTS/CTS <strong>et</strong> Polling. Parmis ces méthodes, on distingue deux<br />
types de méthodes; DCF (Distributed Coordination Function) <strong>et</strong> PCF (Point<br />
Coordination Function). CSMA/CA <strong>et</strong> RTS/CTS sont des méthodes dites DCF car la<br />
gestion de l’accès au canal est laissée au stations. A contrario, Polling est une méthode<br />
PCF car l’accès au canal est gérer par un AP. Seules les méthodes PCF perm<strong>et</strong>tent de<br />
garantir la qualité de service.<br />
IFS<br />
Un intervalle de temps appelé IFS (Interframe Space) à été défini pour<br />
perm<strong>et</strong>tre la gestion de l’accès au canal. C<strong>et</strong> intervalle de temps représente le<br />
temps écoulé <strong>entre</strong> deux trames. La norme propose quatre intervalles de temps<br />
différents :<br />
• SIFS (Short ou Small IFS)<br />
• PIFS (Point Coordination Function IFS)<br />
• DIFS (Distributed Coordination Function IFS)<br />
• EIFS (Extended IFS)<br />
SIFS < PIFS < DIFS < EIFS<br />
1 CSMA/CA : Carrier Sense Multiple Access with Collision Avoidance<br />
29
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
2.6.4.1 CSMA/CA<br />
Avant de commencer à ém<strong>et</strong>tre une station doit sonder le canal pour savoir si il<br />
est libre. Si la station désirant ém<strong>et</strong>tre ne détecte aucune activité pendant un<br />
temps DIFS alors elle ém<strong>et</strong> sa trame. Si une activité est détectée sur le canal<br />
pendant la période DIFS, la station diffère l’envoi de la trame <strong>et</strong> lance le<br />
processus de Backoff. Le processus de Backoff (Backoff process) consiste, dans<br />
un premier temps, à calculer un nombre aléatoire compris en zero <strong>et</strong> CW 1<br />
(Contention Window, fenêtre de contention). Ce nombre est ensuite multiplié<br />
avec durée appelée slot time 2 . Le résultat de la multiplication perm<strong>et</strong> à la station<br />
d’initialiser un timer. Le timer est ensuite décrémenté jusqu’à zero. Si le aucune<br />
activité n’est détectée, la station est autorisée à ém<strong>et</strong>tre. Si, au contraire, la<br />
station détecte une activité elle stoppe son timer. Lorsque le canal redevient<br />
libre, la station attend DIFS <strong>et</strong> reprend la décrémentation du timer.<br />
La figure ci-dessous montre l’envoi <strong>et</strong> l’acquittement d’une trame, l’utilisation<br />
des IFS est bien mis en évidence dans c<strong>et</strong> exemple.<br />
Figure 6 : Envoi de donnée avec quittancement (source : Lawrence Landweber, Jun Murai)<br />
1 CW peut prendre des valeurs différentes en fonction de la modulation utilisée. Ainsi en FHSS, CW<br />
peut valoir <strong>entre</strong> 15 <strong>et</strong> 1023, alors qu’en DSSS CW est compris <strong>entre</strong> 31 <strong>et</strong> 1023.<br />
2 Un slot time est intervalle de temps définit par la norme. La durée d’un slot est de 50 μs lorsque la<br />
couche PMD travaille en FHSS <strong>et</strong> 20 μs pour une modulation DSSS.<br />
30
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Bien que c<strong>et</strong>te méthode perm<strong>et</strong>te de limiter les collisions, il est cependant<br />
possible que deux stations viennent à ém<strong>et</strong>tre en même temps. Dans ce cas, il y<br />
a une collision <strong>et</strong> la trame est perdue. Contrairement aux réseaux câblés utilisant<br />
CSMA/CD, une station <strong>802.11</strong> n’a pas les moyen de détecter une collision.<br />
Chaque trame doit donc être acquittée par la station de destination. Lorsqu’une<br />
trame n’est pas acquittée, la station r<strong>et</strong>ransm<strong>et</strong> la trame après avoir attendu<br />
DIFS <strong>et</strong> un processus de Backoff.<br />
La probabilité d’avoir des collisions sur le canal dépend de la dimension de la<br />
fenêtre de contention CW. Plus la fenêtre est grande, plus la probabilité que les<br />
temps d’attente de deux stations soit identique est faible. Cependant une fenêtre<br />
de contention trop importante nuit aux performances car les temps d’attente<br />
sont plus long. La solution consiste à contrôler dynamiquement la dimension de<br />
la fenêtre de contention. CW est donc recalculé en fonction du nombre de<br />
collisions détectées sur le canal. A chaque collision détectée, la formule est la<br />
suivante :<br />
CW i = 2CW i-1 +1<br />
Équation 1 [MRN<strong>WLAN</strong>]<br />
31
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
2.6.4.2 RTS/CTS<br />
Les <strong>WLAN</strong> sont victimes d’un phénomène appelé « station cachée » (hiddenstation).<br />
La figure ci-dessous perm<strong>et</strong> de mieux comprendre le problème.<br />
Figure 7 : Station cachée<br />
Les stations STA1 <strong>et</strong> STA3 sont trop éloignées l’une de l’autre pour pouvoir<br />
détecter si l’autre est en train de transm<strong>et</strong>tre. Donc si STA1 transm<strong>et</strong> des<br />
informations à STA2 <strong>et</strong> que STA3 désire faire de même, il y aura une collision<br />
car STA3 n’a pas détecter la transmission <strong>entre</strong> STA1 <strong>et</strong> STA2.<br />
RTS/CTS résout le problème des stations cachées. Lorsqu’une stations désire<br />
transm<strong>et</strong>tre une trame, elle commence par envoyer une trame RTS (Request To<br />
Send) après avoir attendu un temps DIFS <strong>et</strong> un temps aléatoire. La trame RTS<br />
perm<strong>et</strong> de réservé le canal pendant la durée de la transmission.<br />
Figure 8 : Trame RTS (source : [<strong>WLAN</strong>99])<br />
32
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
La trame RTS contient la durée de la transmission (champ Duration). Chaque station,<br />
hormis la station destinatrice, sait alors que le canal est réservé <strong>et</strong> pour combien de<br />
temps. Afin de savoir quand elles pourront recommencer à ém<strong>et</strong>tre, les stations utilise<br />
un NAV (N<strong>et</strong>work Allocation Vector). Le NAV est initialisé à partir de la durée<br />
transmise par la trame RTS. Lorsqu’une station reçoit un RTS qui lui est destiné, elle<br />
attend SIFS <strong>et</strong> envoie une trame CTS. Une station n’ayant pas reçu de RTS, car trop<br />
éloignée de la station ém<strong>et</strong>trice, peut recevoir le CTS <strong>et</strong> configurer son NAV.<br />
Figure 9 : Trame CTS (source : [WL99])<br />
Le mécanisme utilisé par RTS/CTS peut laisser penser qu’il est moins performant que<br />
CSMA/CA car il nécessite l’envoi de deux trames avant de pouvoir ém<strong>et</strong>tre de<br />
l’information. Cela est vrai mais seulement dans le cas où la longueur des données est<br />
p<strong>et</strong>ite. Le fait qu’avec RTS/CTS les collisions ne peuvent survenir que pendant l’envoi<br />
de la trame RTS garantit que de longues trames ne seront pas à répéter suite à une<br />
collision. Pour optimiser les transmissions un RTS threshold (seuil) à été introduit.<br />
Lorsque les trames à envoyer sont p<strong>et</strong>ites c’est CSMA/CA qui est utilisé. Dans le cas<br />
où les trames sont plus grandes qu’un certain seuil (RTS Threshold), c’est alors<br />
RTS/CTS qui est utilisé.<br />
Figure 10 : Fonctionnement de RTS/CTS (source : Lawrence Landweber, Jun Murai)<br />
33
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
2.6.4.3 Polling<br />
La méthode du Polling est une méthode PCF (Point Coordination Function),<br />
elle nécessite un point de coordination (PC, Point Coordination). Le point de<br />
coordination est un AP, le Polling ne fonctionne donc pas dans un réseau ad<br />
hoc.<br />
Le PC contrôle périodiquement l’envoi des trames pendant des périodes sanscontention<br />
(CFP, Contention-Free Period). Les CFP sont alternées avec des<br />
périodes de contention DCF durant lesquelles les stations sont habilitées à<br />
envoyer des trames. La fréquence des répétitions des CFP est déterminée par le<br />
CFPRate (taux de périodes sans-contention). Une CFP commence par la<br />
transmission d’un beacon. Le beacon contient la durée de la CFP<br />
(CFPMaxDuration), ce qui perm<strong>et</strong> aux stations du BSS d’initialiser leur NAV 1 ,<br />
garantissant ainsi qu’aucune d’<strong>entre</strong> elles n’ém<strong>et</strong>tra pendant la CFP.<br />
Figure 11 : PCF <strong>et</strong> DCF (source : Lawrence Landweber, Jun Murai)<br />
Lorsque le PC désire commencer une CFP, il attend PIFS avant de transm<strong>et</strong>tre le<br />
beacon. Comme les stations en mode DCF ne peuvent ém<strong>et</strong>tre qu’après un temps<br />
DIFS, le PC est certain de prendre le contrôle car DIFS est plus grand que PIFS. Afin<br />
1 Le NAV est un compteur qui indique à chaque station si elle est autorisée à ém<strong>et</strong>tre. (Voir page<br />
précédente)<br />
34
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
de déterminer l’ordre des stations avec lesquelles il doit dialoguer, le PC tient à jours<br />
une liste appelée Polling List. C<strong>et</strong>te liste contient les adresses (AID, Assiociation<br />
Identififier) des stations désirant communiquer avec le PC. Les stations sont ensuite<br />
consultées à tour de rôle par le PC en fonction de la liste. Les stations attendent SIFS<br />
avant de répondre au PC <strong>et</strong> le PC attend à nouveau SIFS avant de passer à la station<br />
suivante. Le PC termine une CFP par une trame CF-End. Lorsque les stations<br />
recoivent un CF-End, elle efface leur NAV <strong>et</strong> sont à nouveau habilité à travailler en<br />
DCF. Le CF-End marque le passage d’une période sans contention (CFP) à une<br />
période avec contention.<br />
En plus du CF-end <strong>et</strong> du beacon, deux autres trames ont été spécifiées pour le<br />
polling ; CF-Poll <strong>et</strong> CF-Ack. CF-Poll perm<strong>et</strong> au PC de désigné la station avec laquelle<br />
il désire communiquer. CF-Ack est utilisé aussi bien par le PC que par les stations<br />
pour acquitter les trames reçues.<br />
Le Polling, contrairement à CSMA/CA <strong>et</strong> RTS/CTS, perm<strong>et</strong> de garantir la qualité de<br />
service.<br />
2.6.5 Fragmentation<br />
Afin d’optimiser les performances, la couche MAC offre un service de<br />
fragmentation. En eff<strong>et</strong>, dans le cas où la probabilité d’erreur par bit est<br />
importante, le fait d’envoyer des trames trop longues rend la probabilité qu’elles<br />
soient erronées trop importante. Pour diminuer le risque de devoir réenvoyer<br />
une trame suite à une erreur, il s’agit de diminuer la dimension des trames en les<br />
fractionnant en trames plus p<strong>et</strong>ites.<br />
La fragmentation est différente pour CSMA/CA <strong>et</strong> RTS/CTS. Avec CSMA/CA,<br />
lorsqu’une station à accès au canal, elle le conserve jusqu’à ce que tous les fragments<br />
soient transmis. Chaque segment doit biensur être acquitter séparément.<br />
Avec RTS/CTS, le principe est un peu différent. Lorsqu’une station a pris le contrôle<br />
du canal, les autres stations ont initialisé leur NAV. Le NAV des stations qui ne<br />
communiquent pas doit être réinitialisé par les deux stations pendant la<br />
communication. Pour cela, les nouvelles durées de réservation pour la réinitialisation<br />
des NAV sont incluse dans les fragments <strong>et</strong> les acquittements échangés par les<br />
35
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
stations. A la fin de la transmission, le dernier fragment <strong>et</strong> le dernier acquittement ne<br />
contiennent aucune réservation (durée de la reservation égale à 0).<br />
2.6.6 Synchronisation<br />
Toutes les stations appartenant à un même BSS sont synchronisées par la même<br />
horloge. En eff<strong>et</strong> chaque station dispose d’une horloge interne mais se synchronise à<br />
l’horloge commune au BSS. La procédure de synchronisation (TSF, Timing<br />
Synchronisation Function) est réalisée par la diffusion périodique 1 d’un beacon<br />
contenant un timer. La gestion de la synchronisation est différente pour un réseau ad<br />
hoc que pour un réseau basé sur infrastructure.<br />
Synchronisation dans réseau basé sur infrastructure<br />
L’AP est chargé d’envoyer périodiquement le beacon. Dans le cas où le canal est<br />
occupé au moment de la synchronisation, l’émission du beacon est r<strong>et</strong>ardée. Le<br />
temps indiqué dans le beacon est donc incorrecte. L’inéxacitude sera conservée<br />
jusqu’à la procédure de synchronisation suivante, qui intervient TBTT après<br />
(sans compter le r<strong>et</strong>ard).<br />
Synchronisation dans un réseau ad hoc<br />
Un réseau ad hoc ne dispose pas d’AP, c’est donc aux stations de se<br />
synchroniser <strong>entre</strong> elles. Comme pour n’importe quelle trame, toutes les stations<br />
essaient envoyer leur beacon. Les méthode d’accès au canal décrites dans les<br />
paragraphes précédents perm<strong>et</strong>trons de déterminer quelle est la station dont le<br />
beacon sera utilisé pour synchroniser l’ensemble des stations.<br />
2.6.7 Power-Saving Mode<br />
La norme <strong>802.11</strong> définit un moyen d’économiser l’énergie. Cela perm<strong>et</strong> à <strong>802.11</strong> d’être<br />
mieux adapté aux équipements fonctionnant avec des batteries <strong>et</strong> pour qui l’énergie est<br />
précieuse. Pour réduire sa consommation en énergie, une station peut, lorsqu’elle n’a<br />
pas besoin de communiquer, se m<strong>et</strong>tre à l’état Doze. A l’opposer, lorsqu’une station<br />
1 Une période est appelée TBTT (Targ<strong>et</strong> Beacon Transmission Time)<br />
36
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
désirant communiquer doit se trouver dans l’état Awake. Comme pour la<br />
synchronisation, les méthodes de sauvegarde d’énergie sont différentes pour un BSS<br />
basé sur infrastructure <strong>et</strong> un BSS ad hoc.<br />
Sauvegarde d’énergie dans un réseau basé sur infrastrucure<br />
L’AP insère dans une liste les stations qui sont dans le mode doze. Lorsque l’AP reçoit<br />
une trame destinée à une station dans le mode doze, il la conserve en mémoire.<br />
Périodiquement l’AP diffuse un beacon contenant la liste des adresses des stations<br />
pour lesquelles il a un message en mémoire, c<strong>et</strong>te liste est appelée TIM (Traffic<br />
Indication Map). Les stations sont programmées pour se réveiller (mode awake) à<br />
chaque beacon <strong>et</strong> ainsi être en mesure de recevoir la liste TIM. Les stations<br />
n’appartenant pas à la liste r<strong>et</strong>ourne dans le mode Doze. Si une station se reconnaît<br />
dans la liste fournie par l’AP, elle envoie alors une trame PS-Poll indiquant à l’AP de<br />
lui faire parvenir les trames qui lui sont destinées. L’AP transm<strong>et</strong> les trames <strong>et</strong> la<br />
station concernée les acquitte. Les stations peuvent alors se rem<strong>et</strong>tre en mode Doze.<br />
Lorsque l’AP doit transm<strong>et</strong>tre une trame multicast ou broadcast, il utilise alors un<br />
beacon contenant le champ DTIM (Delivery Traffic Indication Message) à la place du<br />
champ TIM. Dans ce cas, toutes les stations doivent rester éveillées <strong>et</strong> recevoir la<br />
trame multicast ou broadcast.<br />
Sauvegarde d’énergie dans un réseau ad hoc<br />
Comme un réseau ad hoc ne dispose pas d’AP, chaque station doit conserver en<br />
mémoire les trames qu’elle désire transm<strong>et</strong>tre à des stations endormies (mode Doze).<br />
Périodiquement les stations endormies se réveillent pour recevoir le beacon, elles<br />
restent alors éveillées pendant une durée appelée fenêtre ATIM (ATIM window).<br />
Pendant la fenêtre ATIM, les stations ayant des trames à échanger à des stations qui<br />
étaient endormies envoie leur liste de stations (ATIM, Ad hoc Traffic Indication Map).<br />
Au bout de la fenêtre ATIM, les stations qui n’ont aucune trame à recevoir r<strong>et</strong>ourne<br />
en mode Doze, les autres acquittent la liste reçue, reçoivent les données qui leur sont<br />
destinées <strong>et</strong> les acquittent.<br />
37
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
2.7 Couche physique<br />
2.7.1 Services offerts par la couche physique<br />
La couche physique m<strong>et</strong> à disposition deux types de primitives ; service-user-to-serviceprovider<br />
<strong>et</strong> sublayer-to-sub-layer.<br />
Primitive PHY-SAP service-user-to-service-provider<br />
PHY-DATA<br />
Encapsulation des trames MAC dans des trames PLCP.<br />
Tableau 5 : Primitive service-user-to-service-provider (source : [<strong>WLAN</strong>99])<br />
Primitives PHY-SAP sublayer-to-sublayer<br />
PHY-TXSTART<br />
Perm<strong>et</strong> a la couche MAC de débuter la transmission d’une MPDU.<br />
PHY-TXEND<br />
La couche MAC demande la fin de la transmission.<br />
PHY-RXSTART<br />
La couche physique indique à la couche MAC qu’elle a reçu une trame<br />
PLCP.<br />
PHY-RXEND<br />
Indique à la couche MAC la fin d’une MPDU qu’il est en train de recevoir.<br />
PHY-CCA<br />
La couche physique indique à la couche MAC si elle se trouve dans l’état<br />
IDLE ou BUSY.<br />
PHY-CCARESET<br />
38
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
La couche MAC demande de réinitialiser l’état CCA (Clear Channel<br />
Assesment).<br />
Tableau 6 : Primitives sublayer-to-sublayer (source : [<strong>WLAN</strong>99])<br />
Paramètres des primitives PHY-SAP<br />
Tableau 7 : Paramètres des primitives PHY-SAP (source : [<strong>WLAN</strong>99])<br />
La liste des paramètre contient des vecteurs (TXVECTOR <strong>et</strong> RXVECTOR), ces<br />
vecteurs sont des listes de paramètres qui dépendent des spécifications de la couche<br />
physique. Le tableau ci-dessous montre les paramètres obligatoires associés aux<br />
vecteurs. DATARATE spécifie le débit, alors que LENGTH détermine la longueur<br />
des paqu<strong>et</strong>s.<br />
Tableau 8 : Description des vecteurs (source : [<strong>WLAN</strong>99])<br />
39
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
2.7.2 DSSS<br />
DSSS signifie Direct Sequence Spread Spectrum, il s’agit d’une technique de<br />
modulation à spectre étalé. Toute modulation à spectre étalé présente les<br />
caractéristiques suivantes :<br />
• La largeur de bande du signal après modulation est plus grande qu’avant la<br />
modulation.<br />
• La largeur de bande du signal transmis dépend du signal transmis <strong>et</strong> d’un<br />
signal supplémentaire appelé code d’étalement (Spreading Code).<br />
Le fait d’étaler l’énergie du signal sur une bande plus large perm<strong>et</strong> de diminuer la<br />
densité de puissance <strong>et</strong> d’augmenter la redondance. Ces deux caractéristiques sont très<br />
importantes.<br />
• Densité de puissance (power density)<br />
Etant donné que le spectre est étalé sur une bande plus large, la puissance de<br />
chaque fréquence est elle aussi plus faible. Grâce à cela, le signal perturbe<br />
moins les communication d’autre système mais est aussi moins sensible aux<br />
perturbations d’un autre système. C<strong>et</strong>te dimunution de la puissance perm<strong>et</strong><br />
aussi au signal d’être moins facilement détectable par un système « espion », ce<br />
qui augmente la sécurité d’une transmission.<br />
40
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Figure 12 : Eff<strong>et</strong> de l’interférenmce avec un signal de bande étroite<br />
(source : IEEE <strong>802.11</strong>)<br />
Comme le montre la figure ci-dessus, la modulation à spectre étalé est<br />
particulièrement efficace en cas d’interférence avec un signal de bande étroite<br />
(narrowband).<br />
• Redondance<br />
La redondance signifie que l’information contenue dans le signal est présente<br />
à plusieurs fréquences différentes. Ainsi en cas d’interférence avec un signal<br />
de bande étroite, il est possible, sauf cas défavorables, de restituer le signal<br />
d’origine.<br />
DSSS est de loin la technique de modulation à spectre étalé la plus utilisée lors<br />
l’application de la norme <strong>802.11</strong>. L’étalement du spectre est obtenu en multipliant le<br />
signal à transm<strong>et</strong>tre par une séquence d’étalement (spreading sequence). Le schéma de la<br />
page suivante montre le principe de fonctionnement de DSSS, la séquence d’étalement<br />
correspond à celle définie par la norme.<br />
41
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Figure 13 : Principe de fonctionnement de DSSS (source : IEEE <strong>802.11</strong>)<br />
Avant d’être étalé le signal est modulé une première fois. Pour cela deux techniques de<br />
modulation sont à disposition ; DBPSK (Differential Binary Phase Shift Keying) <strong>et</strong><br />
DQPSK (Differential Quaternary Phase Shift Keying). La modulation DBPSK est<br />
utilisée pour les transmissions à 1 Mbps, alors que la modulation DQPSK est utilisée<br />
pour celles à 2 Mbps. Pour obtenir des débit de 5,5 <strong>et</strong> 11 Mbps, <strong>802.11</strong>b utilise un<br />
codage CCK (Complementary Code Keying) avec une modulation DQPSK. Après<br />
modulation, le spectre du signal suit le gabarit de la figure ci-dessous.<br />
Figure 14 : Spectre d’un signal modulé en DSSS (source : IEEE <strong>802.11</strong>)<br />
42
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Quatorze canaux ont été définis par la norme <strong>802.11</strong>b pour l’émission en DSSS dans<br />
la bande de fréquence ISM 2,4 GHz. La réglementation en vigueur dans certains états<br />
limite cependant les bandes de fréquences disponibles. Le tableau suivant présente les<br />
limitations imposées par certains états. L’ETSI (norme ETS 300-328) est l’organisation<br />
qui s’occupe de la réglementation européene, alors que la FCC (15.247, 15.205 <strong>et</strong><br />
15.209), l’IC <strong>et</strong> la MKK s’occupe respectivement des USA, du Canada <strong>et</strong> du Japon.<br />
Tableau 9 : Canaux DSSS disponibles<br />
Il existe aussi des disparités <strong>entre</strong> états au niveau des puissances d’émissions. Les<br />
américains, les européens <strong>et</strong> les japonais peuvent ém<strong>et</strong>tre à des puissances maximums<br />
qui sont respectivement de 1000, 100 <strong>et</strong> 10 mW. Cependant la plupart des<br />
équipements <strong>802.11</strong>b utilisent une puissance d’émission de 30 mW (15 dBm).<br />
43
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Une trame PLCP se divise en trois parties ; le PLCP Preambule, le PLCP header <strong>et</strong> la<br />
MPDU (trame MAC). Le PLCP Preambule <strong>et</strong> le PLCP Header sont toujours transmis<br />
à 1Mbps.<br />
Tableau 10 : Trame PLCP en DSSS (source : [<strong>WLAN</strong>99])<br />
SYNC<br />
Ce champ perm<strong>et</strong> au récepteur de la trame de se synchroniser.<br />
SFD prépare le récepteur à recevoir le PLCP Header.<br />
SIGNAL indique la modulation utilisée pour la transmission déterminant ainsi le débit<br />
utilisé. La valeur du champ doit être multipliée par 100 kbps pour obtenir le débit.<br />
SERVICE<br />
Ce champ est destiné à de future extensions.<br />
LENTH<br />
Longueur de la MPDU en microsecondes.<br />
CRC<br />
Détecte <strong>et</strong> corrige les erreurs.<br />
.<br />
44
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
2.7.3 FHSS<br />
Le principe de FHSS est simple, il s’agit de modifier périodiquement la fréquence<br />
utilisée pour la transmission du signal en suivant pour cela une sequence prédifine. Le<br />
passage d’une fréquence à une autre est appelé hop. Une séquence est composée de<br />
hop, c’est pour cela qu’elle est couramment appelée hopping sequence. FHSS est une<br />
technique apparue pendant la seconde guerre mondiale. Elle l’œuvre de Hedy Lamarr,<br />
une actrice autrichienne qui travaillait pour les Alliés.<br />
FHSS est peu utilisé dans les applications basées sur la norme <strong>802.11</strong>. Dans le cadre de<br />
l’étude de la coexistence, une description détaillée de FHSS dans <strong>802.11</strong> n’est pas<br />
nécessaire.<br />
FHSS utilise une séquence pseudo-aléatoire composée de 79 hops 1 par seconde.<br />
L’intervalle minimum de fréquence <strong>entre</strong> deux hops est de 6 MHz. La norme <strong>802.11</strong><br />
définit deux débit possibles pour la transmission en FHSS ; 1 Mbps <strong>et</strong> 2 Mbps 2 . FHSS<br />
utilise une modulation GFSK à deux déviation de fréquence pour les transmissions à 1<br />
Mbps <strong>et</strong> à quatre déviation de fréquence pour les transmission à 2 Mbps.<br />
La figure ci-dessous montre la structure d’une trame PCLP (PCLP_PDU), la<br />
description des champs n’est pas traitée dans ce document.<br />
Figure 15 : Trame PLCP en FHSS (source : [<strong>WLAN</strong>99])<br />
1 Il existe des différences selon les réglementations gouvrnementales.<br />
2 2 Mbps est optionel.<br />
45
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
2.7.4 Infrarouge (IR)<br />
L’infrarouge n’est pratiquement pas utilisé à l’heure actuelle. Comme il est basé sur la<br />
lumière 1 , il ne pose aucun problèmes de compatibilité électromagnétique <strong>et</strong><br />
n’intervient donc pas dans l’étude de la coéxistence <strong>entre</strong> Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong>. Il n’est<br />
pas nécessaire d’en faire une description complète dans le cadre de ce document.<br />
Le fonctionnement de <strong>802.11</strong> IR est proche de celui en DSSS <strong>et</strong> FHSS. Cependant<br />
l’utilisation de l’infrarouge limite la portée de l’ém<strong>et</strong>teur à une dizaine de mètre. Deux<br />
débits sont proposés : 1 <strong>et</strong> 2 Mbps.<br />
Figure 16 : Trame PLCP (source : [<strong>WLAN</strong>99])<br />
1 Infrarouge, longueur d’onde de 850 à 950 nm<br />
46
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
47
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3 Blu<strong>et</strong>ooth<br />
48
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3.1 Introduction<br />
En l'an de grâce 908, un enfant du nom de Harald est né au Danemark. Son père<br />
Gorm gouvernait la péninsule principale du Danemark. Harald a réussi à réunir la<br />
Norvège <strong>et</strong> le Danemark. Il était surnommé Harald Blätand (Dents bleu). Comme<br />
Harald, le but d'Ericsson est d'unifier les nouvelles technologies sans fil nommées<br />
Blu<strong>et</strong>ooth.<br />
Équation 2 : Le roi Harald Blätand (Blue Tooth) [source<br />
www.japaninc.n<strong>et</strong>/mag/comp/2000/ 06/jun00_unwired_btooth.html]<br />
Un SIG (groupe spécial d'intérêt) a été créé en février 1998 pour définir <strong>et</strong><br />
promouvoir Blu<strong>et</strong>ooth. Les membres créateurs étaient :<br />
• Ericsson Mobile Communication<br />
• Intel Corp.<br />
• IBM Corp.<br />
• Toshiba Corp.<br />
• Nokia Mobile Phones<br />
Une <strong>entre</strong>prise désirant rejoindre le groupe doit remplir un formulaire. Elle s'engage<br />
néanmoins à rendre publique les technologies qu'elle détient sur Blu<strong>et</strong>ooth. Tout<br />
membre du groupe, a le droit de commercialiser des produits Blu<strong>et</strong>ooth sans payer<br />
l'utilisation des brev<strong>et</strong>s. Actuellement plus de 2000 compagnies sont membre du SIG.<br />
Blu<strong>et</strong>ooth est une technologie sans fil qui utilise les ondes électromagnétiques sur la<br />
bande de fréquence libre <strong>entre</strong> 2.4 Ghz <strong>et</strong> 2.483 Ghz. C<strong>et</strong>te bande de fréquence<br />
s'appelle ISM <strong>et</strong> aucune licence n'est nécessaire.<br />
49
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
La première priorité de Blu<strong>et</strong>ooth était de créer un système de moins de 1 US$ <strong>et</strong> de<br />
consommer un minimum pour être intégrable dans tous les appareils électroniques<br />
portatifs possible <strong>et</strong> imaginable.<br />
3.2 L'architecture du protocole<br />
Blu<strong>et</strong>ooth ne définit pas uniquement un système de transmission radio, il possède une<br />
pile de protocole software. La pile de protocole entière de Blu<strong>et</strong>ooth est définie en<br />
couche comme la plupart des systèmes de communication.<br />
Figure 17 : Pile de protocole du noyau Blu<strong>et</strong>ooth [source http://tp.blu<strong>et</strong>ooth.free.fr ]<br />
50
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Pour standardiser les différents protocoles, l'International Standard Organization<br />
(ISO) a défini un modèle de référence qui est appelé OSI. Une correspondance peut<br />
être faite <strong>entre</strong> Blu<strong>et</strong>ooth <strong>et</strong> le modèle OSI (voir Figure 18).<br />
Figure 18 : Comparaison <strong>entre</strong> Blu<strong>et</strong>ooth <strong>et</strong> le modèle OSI<br />
3.2.1 Accès au canal de transmission<br />
Afin de pouvoir l'utiliser au niveau planétaire, la technologie Blu<strong>et</strong>ooth opère dans la<br />
bande ISM. C<strong>et</strong>te bande de fréquence est libre d'utilisation partout dans le monde<br />
(sauf restriction au Japon, France <strong>et</strong> Espagne).<br />
De nombreux systèmes sont utilisés dans c<strong>et</strong>te bande de fréquence libre. On peut citer<br />
WLan, écouteurs sans fil, système de sécurité pour les voitures <strong>et</strong> les fours à micro-<br />
51
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
ondes. Blu<strong>et</strong>ooth utilise une technique efficace (mais qui ne l'est pas toujours) pour<br />
éviter les interférences qui s'appelle les sauts de fréquence (appelé Frequency Hopping<br />
ou FH).<br />
Le FH a été inventé durant la seconde guerre mondial par Hedy Lammarr. Le principe<br />
est d'effectuer, comme son nom l'indique, des sauts de fréquence après chaque<br />
transmission (voir Figure 19). L'ém<strong>et</strong>teur <strong>et</strong> le récepteur doivent connaître la séquence<br />
des sauts pour que la communication soit possible. Chaque saut est appelé hop. Dans<br />
Blu<strong>et</strong>ooth, le nombre normal de hops par seconde <strong>et</strong> de 1600.<br />
fréquence<br />
2.48<br />
2.47<br />
2.46<br />
2.45<br />
2.44<br />
2.43<br />
2.42<br />
2.41<br />
2.4<br />
0 1 2 3 4 5 6 7 8 9 10 11 12<br />
temps<br />
Figure 19 : Représentation des sauts de fréquence<br />
Dans la majorité des pays, la bande de fréquence ISM est <strong>entre</strong> 2.4 <strong>et</strong> 2.4835 GHz .<br />
Deux bandes de sécurité se trouve au début <strong>et</strong> à la fin, respectivement 2 MHz <strong>et</strong> 3.5<br />
MHz. Les sauts s'effectue tous les 1 MHz, par conséquent c<strong>et</strong>te formules perm<strong>et</strong> de<br />
trouver un canal k de radiofréquence :<br />
f =2402 +kMHz , k = 0,1 …78<br />
Équation 3<br />
La modulation utilisé est GFSK (Gaussian Frequency Shift Keying) avec un BT = 0.5.<br />
La représentation binaire du 1 est une déviation positive de fréquence <strong>et</strong> pour le 0 une<br />
déviation négative de fréquence. Le débit brute binaire est de 1 Mbit/s.<br />
52
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Figure 20 : modulation GFK [BT01]<br />
Un canal logique Blu<strong>et</strong>ooth est une séquence pseudo-aléatoire qui perm<strong>et</strong> aux<br />
différents dispositifs d'utiliser les mêmes sauts de fréquence. Entre chaque hop, un<br />
slots de temps de 625 microsecondes est numéroté de manière cyclique de 0 à 2 27 -1.<br />
Le cycle total dure :<br />
T 227 62510<br />
6<br />
cycle = ⋅ ⋅<br />
−<br />
= 83886[ s]<br />
Équation 4<br />
L'Équation 4 donne comme résultat 23,3 heures<br />
Bien évidemment, deux dispositifs utilisant des canaux logiques différents ne peuvent<br />
communiquer <strong>entre</strong> eux.<br />
3.3 Classe de puissance<br />
Il existe 3 classes de puissance décrites dans la norme Blu<strong>et</strong>ooth.<br />
Classe de Puissance Maximum Puissance Puissance<br />
puissance de sortie<br />
Nominal minimum de sortie<br />
1 100 mW N/A 1 mW<br />
2 2.5 mW 1 mW 0.25 mW<br />
3 1 mW N/A N/A<br />
Figure 21 : Tableau des classes de puissance<br />
53
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3.4 BaseBand<br />
3.4.1 Architecture<br />
3.4.1.1 Maître <strong>et</strong> Esclave<br />
Pour que plusieurs dispositifs Blu<strong>et</strong>ooth puissent communiquer <strong>entre</strong> eux, il doivent<br />
utiliser les mêmes sauts de fréquence (donc les mêmes séquences pseudo-aléatoire).<br />
Pour synchroniser les sauts de fréquence, ils font appel à un maître qui contrôle la<br />
communication. Tous les dispositifs doivent être maître ou esclave pour pouvoir<br />
transm<strong>et</strong>tre ou recevoir de l'information. Le maître décide quel esclave peut<br />
transm<strong>et</strong>tre.<br />
Les maîtres doivent utiliser les slots pairs <strong>et</strong> les esclaves doivent utiliser les slots<br />
impairs. Le maître indique aux esclaves quand ils peuvent transm<strong>et</strong>tre.<br />
3.4.1.2 Timing<br />
Tout dispositif Blu<strong>et</strong>ooth possède une horloge interne appelée horloge native (<br />
CLKN) qui marque le début des slots. Les horloges internes sont d'assez mauvaise<br />
qualité <strong>et</strong> consomme très peu ce qui provoque rapidement des déphasages. Tous les<br />
esclaves d'un maître se synchronisent continuellement sur l'horloge du maître en<br />
ajoutant temporairement une déviation de phase à leur horloge. La synchronisation<br />
s'effectue à la réception de chaque paqu<strong>et</strong>.<br />
3.4.1.3 Picon<strong>et</strong>s<br />
La construction d'un réseau d'un maître avec plusieurs esclaves est appelée picon<strong>et</strong>s ou<br />
picoréseau (voir Figure 22). Un picon<strong>et</strong> peut inclure jusqu'à 8 éléments actifs, 1 maître<br />
<strong>et</strong> 7 esclaves actifs. Un picon<strong>et</strong> peut, en plus, inclure jusqu'à 255 esclaves parqués. Les<br />
esclaves parqués sont synchronisés sur l'horloge du maître mais attendent un<br />
avertissement de celui-ci pour devenir actifs. L'horloge de référence dans un picon<strong>et</strong><br />
est appelée CLK 1 .<br />
1 Pour le maître du picon<strong>et</strong>, CLKN = CLK<br />
54
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Figure 22 : Représentation d'un picon<strong>et</strong><br />
Il existe aussi la possibilité de m<strong>et</strong>tre plusieurs picon<strong>et</strong>s <strong>entre</strong> eux pour former un<br />
scattern<strong>et</strong> (voir Figure 23). Chaque picon<strong>et</strong> utilise son propre canal logique (sauts de<br />
fréquence) <strong>et</strong> sa propre CLKN.<br />
Un dispositif peut appartenir deux picon<strong>et</strong>s différents mais ne peut pas être maître<br />
dans les deux picon<strong>et</strong>s.<br />
Figure 23 : Scattern<strong>et</strong> où un dispositif joue le rôle d'esclave dans les deux picon<strong>et</strong>s<br />
55
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3.4.1.4 Adresses<br />
Dans la spécification de Blu<strong>et</strong>ooth, il existe quatre types d'adresse.<br />
La BD_ADDR (Blu<strong>et</strong>ooth Device Address) est la correspondance de l'adresse MAC<br />
IEEE MAC. La BD_ADDR identifie de manière univoque, comme l'adresse MAC,<br />
les dispositifs Blu<strong>et</strong>ooth <strong>entre</strong> eux.<br />
Elle se décompose en 3 parties bien distinctes :<br />
• NAP (partie non significative de l'adresse) qui regroupe de 16 bits, c<strong>et</strong>te<br />
partie est utilisée pour l'encryption<br />
• UAP (partie haute de l'adresse) qui regroupe de 8 bits, c<strong>et</strong>te partie sert à<br />
initialiser le HEC <strong>et</strong> le CRC mais aussi pour les sauts de fréquence.<br />
• LAP (partie basse de l'adresse) regroupe 24 bits. C<strong>et</strong>te partie sert à créer<br />
un mot de synchronisation.<br />
Figure 24 : Représentation de l'adresse BD_ADDR<br />
L'adresse du maître de chaque picon<strong>et</strong> doit être connue par tous les esclaves pour que<br />
tous les dispositifs du picon<strong>et</strong> utilisent les mêmes sauts de fréquence.<br />
La AM_ADDR (adresse de membre actif) est une adresse de 3 digits temporaire que<br />
chaque membre actif d'un picon<strong>et</strong> reçoit de la part du maître. C<strong>et</strong>te adresse sert aux<br />
Esclaves pour savoir si un paqu<strong>et</strong> leur est destiné <strong>et</strong> au maître pour différencier les<br />
réponses des différents esclaves. L'adresse 000 est utilisée pour le Broadcasting, c'est<br />
pour c<strong>et</strong>te raison qu'il y a maximum 7 esclaves actifs par picon<strong>et</strong>.<br />
La PM_ADDR (adresse de membre parqué) est une adresse de 8 digits temporaire que<br />
chaque esclave parqué d'un picon<strong>et</strong> reçoit de la part du maître. Un esclave détient<br />
uniquement une PM_ADDR quand il est parqué <strong>et</strong> la perd quand il devient actif.<br />
La AR_ADDR (adresse de requête d'accès) est une adresse utilisée par les esclaves<br />
parqués. Il détermine quels slots peuvent servir pour activer les esclaves en mode<br />
parqué. C<strong>et</strong>te adresse n'est pas unique donc différents esclaves peuvent avoir la même.<br />
56
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3.4.2 Protection des données<br />
Blu<strong>et</strong>ooth utilise différents systèmes pour contrôler <strong>et</strong> corriger les éventuelles erreurs<br />
de transmission.<br />
3.4.2.1 FEC 1/3<br />
Une simple répétition de 3 fois chaque bit (voir Figure 25). La décision est prise à la<br />
majorité de bit. Le FEC 1/3 est utilisé par les entêtes de paqu<strong>et</strong> <strong>et</strong> aussi par les paqu<strong>et</strong>s<br />
de type HV1.<br />
Figure 25 : Codage FEC 1/3 [BT01]<br />
3.4.2.2 FEC 2/3<br />
C<strong>et</strong>te technique utilise un code Hamming (pour 10 bits, ce code en génère 15) avec<br />
comme polynôme générateur :<br />
g ( D)<br />
= ( D+<br />
1) ⋅(<br />
D4 + D+<br />
1)<br />
Équation 5<br />
La distance de Hamming de ce code est de 4, il corrige 1 erreur <strong>et</strong> en détecte 2.<br />
Ce code est généré par un registre à décalage de 5 bits (voir Figure 26).<br />
Figure 26 : Registre à décalage générateur de code Hamming pour FEC 2/3 [BT01]<br />
57
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3.4.2.3 ARQ<br />
Pour les paqu<strong>et</strong>s protégés par un CRC, il y a répétition du paqu<strong>et</strong> en cas de réception<br />
d'un NAK ou si aucun acquittement n'est reçu après un certain temps. Un bit de<br />
séquence évite le problème de doublon si l'acquittement est perdu en route.<br />
3.4.3 Taille des paqu<strong>et</strong>s<br />
Comme nous l'avons précisé précédemment, le maître utilise les slots paird <strong>et</strong> les<br />
esclaves utilisent les slots impairs. Les transmissions se font par paqu<strong>et</strong>s de taille<br />
variable qui peuvent prendre 1, 3 ou 5 slots. A la fin de chaque transmission, sur le<br />
dernier slots de transmission, le paqu<strong>et</strong> ne prend pas tout le temps qui lui est imparti.<br />
C<strong>et</strong>te partie du slot est en fait réservée pour la commutation d'une fréquence à la<br />
suivante. Sur la Figure 27, une transmission de paqu<strong>et</strong>s sur un slot est montrée en<br />
exemple.<br />
Figure 27 : Transmission sur 1 slot [MRNBT]<br />
Un autre exemple pour mieux comprendre en utilisant une transmission avec un<br />
paqu<strong>et</strong> de 5 slots (voir Figure 28).<br />
Figure 28 : Transmission sur 5 slots [MRNBT]<br />
58
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3.4.4 Liaison<br />
Il existe deux types de liaison qu'il faut bien absolument différentier.<br />
3.4.4.1 Liaison SCO<br />
Ce type de liaison est synchrone <strong>et</strong> du type point à point. Elle est habituellement<br />
utilisée pour transm<strong>et</strong>tre de la voix <strong>entre</strong> un maître <strong>et</strong> un esclave. Pour ce type de<br />
liaison, des slots à intervalles réguliers sont réservés pour la transmission. On peut les<br />
considérer comme une liaison commutation de circuit. Le débit symétrique par liaison<br />
SCO est de 64 kbit/s. Il n'y a pas de CRC donc jamais de répétition de paqu<strong>et</strong>s. Un<br />
maître peut <strong>entre</strong>tenir jusqu'à 3 liaisons SCO simultanées avec le même esclave ou<br />
avec différents esclaves.<br />
Il existe 3 types de paqu<strong>et</strong>s SCO définis : HV1, HV2 <strong>et</strong> HV3. Tous ces paqu<strong>et</strong>s<br />
prennent 1 slot mais on un codage différent.<br />
3.4.4.2 Liaison ACL<br />
Ce type de liaison est asynchrone <strong>et</strong> du type point à multipoint. Son utilisation<br />
habituelle est pour la transmission de données. Le débit peut être asymétrique ou<br />
symétrique. Contrairement aux liaisons SCO, il n'y a pas de réservation régulière de<br />
slots. Les slots libres des liaisons SCO sont utilisés par les liaison ACL.<br />
3.4.5 Structure des paqu<strong>et</strong>s<br />
La structure d'un paqu<strong>et</strong> Blu<strong>et</strong>ooth se décompose en trois entités qu'il faut bien<br />
distinguer :<br />
• Le code d'accès,<br />
• l'entête,<br />
• la cargaison.<br />
59
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
La décomposition est faite grâce à leur positionnement comme le montre la Figure 29.<br />
Figure 29 : Représentation normal d'un paqu<strong>et</strong> Blu<strong>et</strong>ooth<br />
3.4.6 Access code<br />
Tous les paqu<strong>et</strong>s commencent forcément par un access code. Il est utilisé pour la<br />
synchronisation, la compensation d'offs<strong>et</strong> <strong>et</strong> l'identification. A la réception d'un<br />
paqu<strong>et</strong>, chaque dispositif peut déterminer si il a été envoyé par un membre du picon<strong>et</strong>.<br />
L'access code est aussi utilisé par les procédures pagging <strong>et</strong> inquiry.<br />
Figure 30 : Le format de l'Access code<br />
3.4.6.1 Access code types<br />
Il y a trois différents types de code d'accès :<br />
• Code d'accès du canal (CAC)<br />
• Code d'accès du dispositif (DAC)<br />
• Code d'accès d'inquiry (IAC)<br />
Le IAC se décompose en deux variantes. Le général code d'accès inquiry (GIAC) <strong>et</strong> le<br />
dédié code d'accès inquiry (DIAC).<br />
Le CAC est le seul (à l'exception des paqu<strong>et</strong> FHS) type de code d'accès qui possède<br />
les trois champs preamble, sync word <strong>et</strong> le trailer. Les autres types ont uniquement les<br />
champs preamble <strong>et</strong> sync word.<br />
60
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3.4.6.2 Preamble<br />
Le préambule est une suite de 1 <strong>et</strong> de 0 sur 4 bits. La séquence représente 1010 si le<br />
premier bit de sync word vaut 1 ou 0101 si le premier bit de sync word vaut 0.<br />
Figure 31 : Séquence du préambule [BT01]<br />
3.4.6.3 Sync Word<br />
Le sync word (mot de synchronisation) est dérivé des 24 bits de l'adresse LAP mais est<br />
long de 64 bits. Pour le CAC, l'adresse du maître est utilisé dans le picon<strong>et</strong>. Pour le<br />
GIAC <strong>et</strong> le DIAC, des adresses dédiées sont utilisées. Mais par contre pour le DAC,<br />
l'adresse de l'esclave est utilisée.<br />
3.4.6.4 Trailer<br />
Le trailer suit le sync word. Comme le préambule, il est formé de 4 bits qui peuvent<br />
prendre les valeurs 1010 <strong>et</strong> 0101.<br />
3.4.6.5 Entête de paqu<strong>et</strong><br />
L'entête des paqu<strong>et</strong>s contient des informations pour la couche link controler. Il est<br />
constitué de 6 champs :<br />
• AM_ADDR : 3 bits (adresse de membre actif=<br />
• Type : 4 bits (type de paqu<strong>et</strong>)<br />
• Flow : 1 bit (contrôle de flux)<br />
• ARQN : 1 bit (acquittement)<br />
• SEQN : 1 bit (numéro de séquence)<br />
• HEC : 8 bits (contrôle des erreurs de l'entête)<br />
L'entête au compl<strong>et</strong> comprend 18 bits (voir Figure 32). Un codage FEC 1/3 est utilisé<br />
pour protégé l'entête, ce qui donne un total de 54 bits.<br />
61
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Figure 32 : Format de l'entête de paqu<strong>et</strong><br />
AM_ADDR :<br />
La AM_ADDR représente l'adresse de membre actif est utilisée pour différencier les<br />
dispositifs dans un picon<strong>et</strong>. L'adresse avec que des 0 consiste en une adresse<br />
broadcast.<br />
Type :<br />
Il existe 16 différents types de paqu<strong>et</strong>. Chaque type définit la liaison (ACL <strong>et</strong> SCO)<br />
utilisée par la transmission. Il perm<strong>et</strong> de connaître le nombre de slots occupés (1,3 ou<br />
5).<br />
Flow :<br />
Ce bit est utilisé pour le contrôle du flux. Si le bit est à 1, la source peut continuer à<br />
ém<strong>et</strong>tre. Si le destinataire ne peut plus suivre (buffer plein par exemple), il m<strong>et</strong> le bit à<br />
0 dans son message. Il faut noter que ceci ne s'applique qu'aux liaisons ACL.<br />
ARQN :<br />
Ce bit est utilisé pour indiquer qu'une transmission a été effectuée correctement ou<br />
non. Le contrôle se fait grâce au CRC.<br />
SEQN :<br />
Ce bit perm<strong>et</strong> d'ordonner les paqu<strong>et</strong>s reçus. Ce bit est inversé à l'envoi de chaque<br />
nouveau paqu<strong>et</strong>.<br />
HEC :<br />
Ces bits servent à contrôler l'entête du paqu<strong>et</strong>. Le HEC est constitué de 8 bits générés<br />
par un polynôme 647 (représenté en octal).<br />
62
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3.4.7 Type de paqu<strong>et</strong><br />
Pour les deux types liaisons (ACL <strong>et</strong> SCO), 12 types de paqu<strong>et</strong> peuvent être définis. Il<br />
existe 4 types de paqu<strong>et</strong> de contrôle commun aux deux liaisons. Pour différencier le<br />
type de paqu<strong>et</strong>, 4 bits sont utilisés (voir 3.4.6.5). Quatre segments ont été définis :<br />
1. Paqu<strong>et</strong>s de contrôle sur 1 slot (commun aux deux liaisons)<br />
2. Paqu<strong>et</strong>s sur 1 slot<br />
3. Paqu<strong>et</strong>s sur 3 slots<br />
4. Paqu<strong>et</strong>s sur 5 slots<br />
Figure 33 : Tableau des types de paqu<strong>et</strong> [BT01]<br />
63
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3.4.7.1 Paqu<strong>et</strong> ID<br />
Ce paqu<strong>et</strong> consiste en un accès code du type DAC ou IAC. C'est un paqu<strong>et</strong> très<br />
robuste au niveau du corrélateur de l'accès code.<br />
3.4.7.2 Paqu<strong>et</strong> NULL<br />
Ce paqu<strong>et</strong> n'a pas de cargaison mais possède un code d'accès <strong>et</strong> un entête de paqu<strong>et</strong>. Il<br />
contient 126 bits au total. Il est utilisé pour envoyer un acquittement ou pour changer<br />
le statue de FLOW. Ce paqu<strong>et</strong> ne doit pas être acquitté.<br />
3.4.7.3 Paqu<strong>et</strong> POLL<br />
Ce paqu<strong>et</strong> est très similaire au paqu<strong>et</strong> de type NULL (voir 3.4.7.2). Il doit cependant<br />
être acquitté.<br />
3.4.7.4 Paqu<strong>et</strong> FHS<br />
FHS est un paqu<strong>et</strong> de contrôle spécial. Parmi d'autres choses, l'adresse de dispositif<br />
Blu<strong>et</strong>ooth <strong>et</strong> l'horloge de l'expéditeur sont envoyés avec le paqu<strong>et</strong>. La cargaison<br />
contient 144 bits d'information <strong>et</strong> 16 bits de CRC. La cargaison est codés en FEC 2/3<br />
ce qui signifie qu'elle occupe 240 bits réellement. Il n'occupe qu'un slot.<br />
Figure 34 : Format de la cargaison d'un paqu<strong>et</strong> FHS [BT01]<br />
Parity bits : 34 bits de parité<br />
LAP : les 24 bits de la partie inférieure de l'adresse (BD_ADDR) de l'expéditeur du<br />
paqu<strong>et</strong> FHS.<br />
Undefined : 2 bits mis à 0 pas encore utilisés.<br />
SR : 2 bits qui indiquent la répétition <strong>entre</strong> deux scan <strong>et</strong> l'intervalle <strong>entre</strong> deux page<br />
scan consécutif.<br />
64
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
SR bit format b 1 b 0 SR mode T page scan N page<br />
00 R0 continus >=1<br />
01 R1 =128<br />
10 R2 =256<br />
11 Réservé - -<br />
Figure 35 : Représentation du champ SR<br />
SP : 2 bits qui indiquent la période pendant laquelle le dispositif se trouve en page scan<br />
après la réception du Inquiry.<br />
SP bit format b1b0 SP mode Tmandatory pscan<br />
00 P0 >=20s<br />
01 P1 >=40s<br />
10 P2 >=60s<br />
11 Réservé -<br />
Figure 36 : Représentation du champ SP<br />
UAP : 8 bits de la partie supérieur de l'adresse (BD_ADDR) de l'expéditeur du paqu<strong>et</strong><br />
FHS.<br />
NAP :16 bits de la partie non-significative de l'adresse (BD_ADDR).<br />
Class of device : 24 bits représentent le type dispositif .<br />
AM_ADDR : 3 bits qui forment l'adresse de membre actif du dispositif qui envoie le<br />
paqu<strong>et</strong> FHS.<br />
CLK 27-2 : 26 bits qui contiennent la valeur de l'horloge native du dispositif qui envoie<br />
le paqu<strong>et</strong> FHS.<br />
65
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Page scan mode : 3 bit qui définissent quel scan mode est utilisé par défaut par le<br />
dispositif qui a envoyé le paqu<strong>et</strong>.<br />
Bit format b 2 b 1 b 0<br />
Page scan mode<br />
000 Manadatory scan mode<br />
001 Optional scan mode I<br />
010 Optional scan mode II<br />
011 Optional scan mode III<br />
100 Réservé pour utilisation futur<br />
101 Réservé pour utilisation futur<br />
110 Réservé pour utilisation futur<br />
111 Réservé pour utilisation futur<br />
Figure 37 : Représentation du champ Page scan mode<br />
3.4.7.5 Paqu<strong>et</strong> DM1<br />
Ce type de paqu<strong>et</strong> est utilisé pour échanger des messages de contrôle des couches<br />
supérieures. Il peut être utilisé par des liaisons SCO pour interrompre le flux<br />
d'information <strong>et</strong> pour envoyer des messages de contrôle. Les paqu<strong>et</strong>s DM1 peuvent<br />
être considérés comme un paqu<strong>et</strong> ACL.<br />
DM est l'abréviation de Data Medium rate. La cargaison du paqu<strong>et</strong> contient 17 bytes<br />
d'information entourées par 1 byte d'entête <strong>et</strong> 2 bytes de CRC. Le codage FEC 2/3<br />
est utilisé pour la cargaison. Il n'occupe qu'1 slot.<br />
3.4.7.6 Paqu<strong>et</strong> HV1<br />
Ce type de paqu<strong>et</strong> utilise une liaison SCO avec uniquement 80 bits d'information. Les<br />
paqu<strong>et</strong>s HV1 sont les plus robustes grâce à leur codage FEC 1/3. Comme tous les<br />
paqu<strong>et</strong>s qui fonctionnent avec une liaison SCO, il ne possède pas de CRC. La taille de<br />
la cargaison est de 240 bits 1 .<br />
1 les 80 bits codés en FEC 1/3 donne : 3*80 = 240 bits<br />
66
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3.4.7.7 Paqu<strong>et</strong> HV2<br />
Ce type de paqu<strong>et</strong> utilise une liaison SCO avec 160 bits d'information. Les paqu<strong>et</strong>s<br />
HV2 sont moins robuste que les paqu<strong>et</strong>s HV1 car ils codent leur cargaison avec un<br />
FEC 2/3. Comme tous les paqu<strong>et</strong>s qui fonctionnent avec une liaison SCO, il ne<br />
possède pas de CRC. La taille de la cargaison, comme pour tous les paqu<strong>et</strong>s HV, est<br />
de 240 bits.<br />
3.4.7.8 Paqu<strong>et</strong> HV3<br />
Ce type de paqu<strong>et</strong> utilise une liaison SCO avec 240 bits d'information sans codage 1 .<br />
Les paqu<strong>et</strong>s HV3 sont, bien évidemment, les moins robustes. Comme tous les paqu<strong>et</strong>s<br />
qui fonctionnent avec une liaison SCO, il ne possède pas de CRC.<br />
3.4.7.9 Paqu<strong>et</strong> DV<br />
Ce type de paqu<strong>et</strong> est une combinaison <strong>entre</strong> un paqu<strong>et</strong> de données (data field) <strong>et</strong> de<br />
transmission de la voix (voice field). Il utilise une liaison SCO. La cargaison est divisée<br />
en une partie pour la voix de 80 bits <strong>et</strong> une partie pour les données jusqu'à 150 bits. La<br />
partie voix n'est pas protégée par un FEC. La partie donnée contient 9 bytes<br />
d'information avec 1 bytes d'entête de cargaison <strong>et</strong> 2 bytes de CRC. C<strong>et</strong>te partie est<br />
codée par un FEC 2/3.<br />
3.4.7.10 Paqu<strong>et</strong> DH1<br />
Ce type de paqu<strong>et</strong> ressemble au DM1 à la différence qu'aucun codage n'est utilisé. Le<br />
nombre de bytes d'information peut donc passer au maximum à 27 bytes.<br />
3.4.7.11 Paqu<strong>et</strong> DM3<br />
Les paqu<strong>et</strong>s DM3 ont la même structure que le DM1 mais il occupe 3 slots. L'entête<br />
de cargaison fait maintenant 2 bytes <strong>et</strong> 121 bytes d'information.<br />
1 Ce qui veut dire qu'il contient aussi 240 bits de cargaison<br />
67
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3.4.7.12 Paqu<strong>et</strong> DH3<br />
Ce type de paqu<strong>et</strong> ressemble au DM3 à la différence qu'aucun codage n'est utilisé. Le<br />
nombre de bytes d'information peut donc passer au maximum à 183 bytes.<br />
3.4.7.13 Paqu<strong>et</strong> DM5<br />
Les paqu<strong>et</strong>s DM5 ont la même structure que le DM3 mais il occupe 5 slots. Il a la<br />
possibilité d'avoir au maximum 224 bytes d'information.<br />
3.4.7.14 Paqu<strong>et</strong> DH5<br />
Ce type de paqu<strong>et</strong> ressemble au DM5 à la différence qu'aucun codage n'est utilisé. Le<br />
nombre de bytes d'information peut donc passer au maximum à 339 bytes.<br />
3.4.7.15 Paqu<strong>et</strong> AUX<br />
Ce type de paqu<strong>et</strong> ressemble au DH1 mais il n'y a pas de CRC. Il peut donc contenir<br />
29 bytes d'information <strong>et</strong> 1 byte d'entête de cargaison. Attention, ce paqu<strong>et</strong> ne peut<br />
pas être acquitté par c<strong>et</strong>te couche. Le contrôle doit donc être fait par une couche<br />
supérieure.<br />
68
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3.4.8 Entête de cargaison<br />
Uniquement les champs de données ont un entête de cargaison. C<strong>et</strong> entête peut faire 1<br />
byte (si le paqu<strong>et</strong> prend 1 slot) ou 2 bytes (si le paqu<strong>et</strong> prend 3 ou 5 slots).<br />
Figure 38 : Entête de cargaison sur 1 byte (prend 1 slot) [BT01]<br />
Figure 39 : Entête de cargaison sur 2 bytes (prend 3 ou 5 slots) [BT01]<br />
L_CH :<br />
Ces 2 bits spécifient le canal logique.<br />
FLOW :<br />
Ce bit contrôle le flux du canal logique. Quand un message est reçu avec FLOW = 1,<br />
on peut continuer à transm<strong>et</strong>tre sur le canal logique. Par contre quand le message<br />
contient FLOW = 0, la transmission est stoppée.<br />
LENGTH :<br />
Ces bits définissent la longueur de la cargaison en byte.<br />
3.4.9 Canaux logique<br />
Avec Blu<strong>et</strong>ooth, il existe 5 canaux logiques :<br />
• Canal de contrôle LC<br />
• Canal de contrôle LM<br />
• Canal utilisateur UA<br />
69
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
• Canal utilisateur UI<br />
• Canal utilisateur US<br />
Les canaux contrôlent LC <strong>et</strong> LM sont utilisés respectivement par les couche link<br />
control <strong>et</strong> link manager. Les canaux utilisateur UA, UI <strong>et</strong> US utilisent des<br />
transmissions asynchrones, isochrones 1 <strong>et</strong> synchrones de l'information<br />
utilisateur.<br />
1 Caractérise des communications où les données sont transmises selon un timing précis.<br />
70
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3.5 Link Controller<br />
3.5.1 Etat du Link Controller<br />
Il existe deux états principaux dans lequel peut être le Link Controller : STANDBY <strong>et</strong><br />
CONNECTION. En plus, 7 sous-état sont disponibles : page, page scan, inquiry,<br />
inquiry scan, master response, slave response <strong>et</strong> inquiry response.<br />
Figure 40 : Diagramme des états de Link Controller [BT01]<br />
71
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3.5.2 Procédure Inquiry<br />
C<strong>et</strong>te procédure est utilisée par un maître pour connaître les dispositifs Blu<strong>et</strong>ooth<br />
présents dans sa zone de couverture. C<strong>et</strong>te procédure peut se décomposer en 3 sousétats<br />
bien distinct.<br />
Figure 41 : Schéma bloc de la procédure Inquiry<br />
3.5.2.1 Sous-état Inquiry<br />
Le maître r<strong>entre</strong> dans c<strong>et</strong> état quand il désire rechercher d'autre dispositif dans sa<br />
zone. La maître ne connaît pas leur adresse BD_ADDR. Le code d'accès utilisé par le<br />
maître est le GIAC. Ce code d'accès est connu <strong>et</strong> identique pour chaque dispositif<br />
Blu<strong>et</strong>ooth. Les dispositifs désirant devenir esclave m<strong>et</strong>tent le GIAC 1 dans leur<br />
corrélateur <strong>et</strong> lance la procédure Inquiry Scan (voir ci-dessous). Une séquence 32<br />
fréquence est estimée (Inquiry Sequence) autour de la fréquence déduit du GIAC.<br />
C<strong>et</strong>te séquence est utile car les deux dispositifs ne sont probablement pas en phase. La<br />
Inquiry Sequence est divisé en deux série A <strong>et</strong> B.<br />
Série A : f(k-8), f(k-7)…, f(k), …f(k+7)<br />
Série B : f(k-16), f(k-15)…, f(k-9), f(k+8), f(k+9)…,f(k+15)<br />
Le maître commence par transm<strong>et</strong>tre Npage (voir Figure 35) fois la série A. Si il ne<br />
trouve pas de dispositif, il passe à la série B qu'il répète aussi Npage. Ces deux séries<br />
transm<strong>et</strong>tent des paqu<strong>et</strong>s ID à une fréquence de 3200 hops/s. Les paqu<strong>et</strong>s sont<br />
tranmis par groupe de deux fréquences puis il écoute sur ces deux fréquences pendant<br />
1 hop chacune.<br />
1 Pour certaines utilisation le code d'accès dédié à l'inquiry existe (DIAC)<br />
72
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Figure 42 : Phase de transmission puis d'écoute du sous-état Inquiry<br />
Temps de transmission d'une série de fréquence :<br />
625μs<br />
= 16 ⋅2⋅<br />
=<br />
2<br />
Ts 10<br />
Équation 6<br />
ms<br />
73
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3.5.2.2 Sous-état Inquiry Scan<br />
Un dispositif <strong>entre</strong> dans c<strong>et</strong> état lorsque il accepte de devenir visible. Elle consiste à<br />
écouter le canal à intervalle régulier Tinquiry_scan (>10.65 ms) pendant un temps<br />
Twinquiry_scan(>= 2.56s). Il calcule une séquence de 32 sauts de fréquence grâce au<br />
GIAC (Inquiry sequence). Durant le temps Tinquiry_scan, le dispositif doit recevoir<br />
toutes les séquence d'une série.<br />
Figure 43 : Représentation des temps d'écoute du sous-état Inquiry Scan<br />
74
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3.5.2.3 Sous-état Inquiry Response<br />
Le dispositif qui est dans l'état Inquiry Scan passe à l'état Inquiry Response quand il<br />
reçoit un paqu<strong>et</strong> ID de la part d'un maître. Il répond au maître sur la même fréquence<br />
sur laquelle il écoutait. Il envoie un message FHS qui contient son BD_ADDR.<br />
Attention, comme plusieurs dispositif peuvent répondre en même temps, il envoie sa<br />
réponse après un temps aléatoire.<br />
3.5.3 Procédure Page<br />
C<strong>et</strong>te procédure est utilisée par un maître pour établir une connexion avec un esclave<br />
quand il connaît l'adresse de celui-ci. Pour ce faire le maître doit envoyé son adresse à<br />
l'esclave. C<strong>et</strong>te procédure peut se décomposer en 3 sous-états bien distinctes.<br />
Figure 44 : Suite de séquences pour la procédure page<br />
3.5.3.1 Sous-état Page<br />
Le maître passe à c<strong>et</strong> état lorsqu'il désire établir la connexion avec un dispositif dont il<br />
connaît la BD_ADDR. C<strong>et</strong> état est très similaire au Inquiry à la différence que les 32<br />
fréquences de la séquence sont déduites du DAC du dispositif qui va devenir esclave.<br />
Il transm<strong>et</strong> des paqu<strong>et</strong>s ID avec le DAC de l'esclave comme code d'accès. Il procède<br />
de le même en ce qui concerne les deux séries.<br />
75
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
3.5.3.2 Sous-état Page scan<br />
L'esclave r<strong>entre</strong> dans c<strong>et</strong> état pour avoir la possibilité de se connecter au picon<strong>et</strong>. C<strong>et</strong><br />
état est très similaire au Inquiry scan, à l'exception que son propre DAC est mis dans<br />
son corrélateur. Il écoute le canal à intervalle régulier Tpage_scan (>10.65 ms)<br />
pendant un temps Twpage_scan(>= 2.56s).<br />
3.5.3.3 Sous-état Page response<br />
L'esclave <strong>entre</strong> dans c<strong>et</strong> état après avoir reçu un paqu<strong>et</strong> ID du maître. Il renvoie un<br />
paqu<strong>et</strong> ID sur la fréquence sur laquelle il écoutait le canal. A ce moment, le maître<br />
connaît la phase <strong>et</strong> peut renvoyer un paqu<strong>et</strong> FHS avec son BD_ADDR. L'esclave fait<br />
maintenant partie du picon<strong>et</strong>.<br />
76
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
77
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
4 <strong>Coexistence</strong><br />
78
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
4.1 Problématique<br />
Les problèmes posés par la cohabitation <strong>entre</strong> Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong> <strong>802.11</strong> sont<br />
difficiles à cernés. Certains utilisateurs se plaindront de fortes pertes de performances<br />
lorsque les deux systèmes fonctionnent simultanément, alors que d’autres ne<br />
trouveront aucun inconvénients lors de la cohabitation des deux systèmes. Ces<br />
inégalités <strong>entre</strong> utilisateurs proviennent du fait que la qualité des transmissions dépend<br />
principalement des paramètres suivants ; environnement spatial, dispositifs parasites<br />
environnant, type de modulation utilisée, puissance d’émission, distance <strong>entre</strong> les<br />
stations, dimension des paqu<strong>et</strong>s, … Ces différents paramètres seront traités en détail<br />
ultérieurement dans le chapitre sur les modèles théoriques.<br />
Que cela porte à conséquence ou non, il y a de toute manière interférence <strong>entre</strong><br />
dispositifs Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong> <strong>802.11</strong>b. Tout simplement car les deux technologies<br />
utilisent la même bande de fréquence. C<strong>et</strong>te bande de fréquence fait partie des bandes<br />
de fréquences ISM, elle s’étend de 2,4 à 2,4835 GHz.<br />
Figure 45 : Spectre de <strong>WLAN</strong> <strong>802.11</strong>b en DSSS<br />
Figure 46 : Spectre de Blu<strong>et</strong>ooth<br />
79
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Les dispositifs Blu<strong>et</strong>ooth module ses signaux en FHSS utilisant ainsi l’ensemble de la<br />
bande de fréquence. La bande est divisée en 79 canaux de 1 MHz, chaque canal est<br />
utilisé à tour de rôle selon une séquence prédéfinie. Chaque passage d’une fréquence à<br />
une autre est appelée hop (saut).<br />
En mode DSSS, <strong>WLAN</strong> <strong>802.11</strong> utilise un canal de 22 MHz à une fréquence définie<br />
qui ne varie pas durant les communications. L’IEEE définit 14 canaux dans la bande<br />
ISM 2,4 GHz. Les lobes secondaires d’un canal sont faibles <strong>et</strong> ne perturbent<br />
pratiquement pas les communications.<br />
Lorsqu’un dispositif Blu<strong>et</strong>ooth passe sur un canal compris dans la bande de 22 MHz<br />
utilisée par un dispositif <strong>WLAN</strong> <strong>802.11</strong>, il y a interférence. Cela n’entraîne pas<br />
forcément une mauvaise transmission. L’importance de l’interférence va dépendre de<br />
la puissance des signaux à l’endroit où ils interfèrent. Le récepteur doit pouvoir<br />
r<strong>et</strong>rouver l’information originale à partir du signal qu’il reçoit. Si ce signal est trop<br />
perturbé, l’information sera mal reçue. Afin de définir l’importance de l’interférence, il<br />
s’agira de déterminer le rapport signal sur interférence (rapport S/I). C<strong>et</strong>te aspect de la<br />
coexistence est développée dans le modèle théorique sur les interférences (voir<br />
chapitre suivant).<br />
80
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
4.2 Comportement des équipements<br />
Cela peut paraître évident mais un chevauchement des fréquences des technologies<br />
Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong> <strong>802.11</strong> n’est possible que si elles ém<strong>et</strong>tent en même temps.<br />
Chacune des technologies possède des techniques différentes pour gérer la<br />
propagation de l’information dans le domaine temporel. Le fait que des dispositifs<br />
Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong> occupe le même espace n’entraîne donc pas qu’ils soient<br />
constamment en train d’ém<strong>et</strong>tre en même temps. Les interférences n’ont donc pas lieu<br />
tout le temps mais dépendent en partie du type de liaison <strong>et</strong> de la taille des trames<br />
utilisés.<br />
Figure 47 : Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong> <strong>802.11</strong> dans le domaine temporel<br />
Le cas de la figure de la page précédente est intéressant. Il s’agit d’une liaison SCO<br />
d’un dispositif Blu<strong>et</strong>ooth, ce type de liaison est particulièrement défavorable car le<br />
canal est quasiment utilisé durant toute la durée d’une communication. Dans ces<br />
conditions un dispositif <strong>WLAN</strong> ne peut envoyer des trames sans que la transmission<br />
ne soit perturbée. Mais le comportement d’un ensemble de dispositifs Blu<strong>et</strong>ooth peutêtre<br />
différent <strong>et</strong> n’entraîne pas nécessairement une perturbation permanente 1 d’un<br />
canal <strong>WLAN</strong>. C<strong>et</strong>te aspect de la coexistence sera décrite plus précisément dans le<br />
modèle théorique.<br />
1 Attention : Il s’agit du domaine temporel. Il faut garder à l’esprit que la fréquence d’émission de<br />
Blu<strong>et</strong>ooth change à chaque slot soit toutes les 625μs <strong>et</strong> que par conséquent le canal <strong>WLAN</strong> n’est de<br />
toute manière pas continuellement perturbé.<br />
81
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
4.3 Prévisions <strong>et</strong> statistiques<br />
4.3.1 Calcul de la probabilité d’interférences<br />
Il est possible par des calculs simples de prévoir quelle peut être la probabilité qu’une<br />
interférence surviennent <strong>entre</strong> dispositifs <strong>WLAN</strong> <strong>et</strong> Blu<strong>et</strong>ooth. Dans la mesure où<br />
<strong>WLAN</strong> utilise une modulation à spectre étalé, une interférence n’entraîne pas<br />
nécessairement une erreur dans la communication, mais connaître la probabilité<br />
d’interférence perm<strong>et</strong> de se faire une première idée en vue de la simulation <strong>et</strong> de la<br />
mesure.<br />
La probabilité d’interférence varie en fonction de la séquence de hop de Blu<strong>et</strong>ooth<br />
mais aussi en fonction de la longueur des trames <strong>WLAN</strong>. Plus le temps nécessaire<br />
pour transm<strong>et</strong>tre la trame est long plus il y a de risque d’interférences. Le temps<br />
nécessaire à la transmission d’une trame dépend de deux éléments ; la longueur de la<br />
trame <strong>et</strong> le débit avec lequel elle est transmise. La probabilité d’interférence dépend<br />
donc de ces deux variables.<br />
Calcul de la durée nécessaire pour transm<strong>et</strong>tre une trame (t) :<br />
t = ⋅N+<br />
1 ⋅(<br />
N preamble+<br />
N<br />
D DPlCP<br />
1<br />
header<br />
Équation 7<br />
)<br />
D : Débit (1, 2, 5,5 ou 11 Mbps)<br />
N : Nombre de bit de la MPDU (trame MAC)<br />
D PLCP : Débit de transmission du PLCP Preamble <strong>et</strong> du PLCP Header (1Mbps)<br />
N Preamble : Nombre de bit du préambule<br />
N Header : Nombre de bit du header<br />
Calcul de la probabilité d’interférence (p):<br />
B<br />
p=<br />
1 −<br />
⎛<br />
⎜1−<br />
⎝<br />
<strong>WLAN</strong><br />
+ ( B<br />
B<br />
Blu<strong>et</strong>ooth<br />
ISM<br />
Équation 8<br />
−1)<br />
⎞<br />
⎟<br />
⎠<br />
1+<br />
t⋅<br />
fhop<br />
82
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
B <strong>WLAN</strong> : Bande de fréquence utilisée par <strong>WLAN</strong> [MHz]<br />
B ISM : Bande ISM [MHz]<br />
B Blu<strong>et</strong>ooth : Bande de fréquence utilisée par Blu<strong>et</strong>ooth [MHz]<br />
f hop : fréquence des hops [hops/s]<br />
Le graphe de la Figure 48 est tiré de l’Équation 8. Bien que réellement la bande de<br />
fréquence utilisée par <strong>WLAN</strong> soit de 20 MHz, la bande de fréquence a été fixée à 15<br />
MHz pour le calcul. Paradoxalement, c<strong>et</strong>te rectification perm<strong>et</strong> d’obtenir des résultats<br />
plus proches de la réalité. Pour comprendre pourquoi, il faut savoir que le 99% de<br />
l’énergie des signaux émis par un dispositif <strong>WLAN</strong> est compris dans une bande de 15<br />
MHz. Il n’est donc pas déraisonnable de considérer que seul les interférences dans la<br />
bande de 15 MHz seront susceptibles de créer des perturbations. C<strong>et</strong>te affirmation a<br />
été confirmée par les observations faites lors des différentes simulations réalisées pour<br />
l’élaboration du modèle théorique.<br />
Figure 48 : Probabilité d’interférence <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong>b <strong>et</strong> Blu<strong>et</strong>ooth<br />
Une autre particularité de ce calcul concerne la fréquence de hops de Blu<strong>et</strong>ooth.<br />
Bien que dans la réalité Blu<strong>et</strong>ooth change de fréquence 1600 fois par secondes, c<strong>et</strong>te<br />
valeur convient mal au but visé par les résultats recherchés. Le but rechercher par ce<br />
calcul est d’obtenir un « gabarit » auquel devrait correspondre les simulations <strong>et</strong> les<br />
83
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
mesures. Or en réalité lorsqu’un dispositif Blu<strong>et</strong>ooth utilise des trames HV1 avec une<br />
liaison SCO 1 , il n’ém<strong>et</strong> que durant un slot sur deux (1 slot pour l’émission, 1 slot pour<br />
la réception). Il s’agit donc de considérer une fréquence de 800 hops par seconde, car<br />
il est évident que la réception d’une trame ne peut perturber une communication <strong>entre</strong><br />
dispositifs <strong>WLAN</strong>. Prendre une fréquence de 800 hops/s, revient à considérer que le<br />
dispositif Blu<strong>et</strong>ooth communique seul, où avec un dispositif infiniment loin.<br />
Considérer qu’un dispositif Blu<strong>et</strong>ooth travaille seul est bien loin de la réalité en ce qui<br />
concerne le fonctionnement d’un réseau Blu<strong>et</strong>ooth lui-même. Mais pour un réseau<br />
<strong>WLAN</strong>, les interférences créés par les réponses d’un second dispositif Blu<strong>et</strong>ooth<br />
distant de plusieurs mètres (>3m) sont trop faibles pour entraîner des erreurs.<br />
En adm<strong>et</strong>tant que deux dispositifs Blu<strong>et</strong>ooth soient en mesures 2 de perturber une<br />
communication <strong>WLAN</strong>, le graphe obtenu est les suivant :<br />
Figure 49 : Probabilité d’interférence <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong>b <strong>et</strong> deux dispositifs Blu<strong>et</strong>ooth<br />
1 Ce cas a été choisi car il représente le cas le plus défavorable.<br />
2 Dans bien des cas la distance <strong>entre</strong> deux dispositifs Blu<strong>et</strong>ooth est assez proche pour qu’ils perturbent<br />
tout les deux une communication <strong>WLAN</strong>. Exemple : heads<strong>et</strong>, souris/clavier sans-fil , …<br />
84
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
La Figure 48 <strong>et</strong> la Figure 49 présente des probabilités d’interférences très élevées,<br />
notamment pour un débit d’un 1 Mbps. Mais la probabilité d’interférences ne reflète<br />
pas exactement quelle sera le taux d’erreur par trame (FER, Frame Error Rate), une<br />
interférence n’entraînant pas nécessairement une erreur après démodulation. Ainsi<br />
bien que les trames transmises à un débit de 1 Mbps semblent plus vulnérables en ce<br />
qui concerne les interférences, le fait que la modulation à 1 Mbps soit plus robuste aux<br />
interférences avec des signaux de bande étroite va perm<strong>et</strong>tre de compenser les<br />
dégradations de performances.<br />
4.3.2 Influence du comportement des dispositifs Blu<strong>et</strong>ooth<br />
Dans la section précédente, la coexistence a été étudiée dans la cas où Blu<strong>et</strong>ooth<br />
utilisait une liaison SCO. Mais Blu<strong>et</strong>ooth dispose d’une autre type de liaison : les<br />
liaisons asynchrones appelées ACL. Contrairement aux liaisons SCO, les paqu<strong>et</strong>s<br />
peuvent occuper plus d’un slot (3 ou 5 slots). Les hops se produisent donc à une<br />
fréquence différente lors des transmissions sur 3 où 5 slots.<br />
Figure 50 : Comparaison <strong>entre</strong> liaison SCO <strong>et</strong> ACL<br />
85
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Comme le montre la Figure 50, avec une liaison ACL utilisant des paqu<strong>et</strong>s DM5 ou<br />
DH5, l’ém<strong>et</strong>teur Blu<strong>et</strong>ooth change de fréquence moins fréquemment. Il s’agit aussi de<br />
distinguer les communications symétrique <strong>et</strong> asymétriques. En eff<strong>et</strong>, le récepteur<br />
Blu<strong>et</strong>ooth peut envoyer en réponse à l’ém<strong>et</strong>teur, soit des paqu<strong>et</strong>s utilisant un slot<br />
(communication symétrique) (comme dans l’exemple de la Figure 50), soit des paqu<strong>et</strong>s<br />
occupant 3 où 5 slots (communication asymétrique).<br />
Le tableau de la Figure 51 contient le nombre de hops par seconde en fonction des<br />
différents types de paqu<strong>et</strong>s Blu<strong>et</strong>ooth :<br />
Figure 51 : Tableau des hops pour les différents types de paqu<strong>et</strong>s<br />
A partir de l’Équation 8, il est alors possible de déterminer la probabilité d’interférence<br />
pour les différents types de paqu<strong>et</strong>s utilisés dans les liaisons ACL.<br />
Les graphiques de la Figure 52 <strong>et</strong> de la Figure 53 présentent la probabilité<br />
d’interférence en fonction de la dimension des trames <strong>WLAN</strong> pour différents types de<br />
liaisons ACL symétriques <strong>et</strong> asymétriques. Le débit <strong>WLAN</strong> est de 11 Mbps. Le graphe<br />
contient aussi les résultats pour la procédure de paging qui utilise 3200 hops/s.<br />
Comme pour la première série de résultats obtenus précédemment, seul les<br />
changements de fréquence de l’ém<strong>et</strong>teur sont considérés.<br />
86
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Figure 52 : Probabilité d’interférence pour les liaison ACL symétriques<br />
Figure 53 : Probabilité d’interférence pour les liaison ACL asymétriques<br />
87
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
4.3.3 Rapport <strong>entre</strong> la probabilité d’interférences <strong>et</strong> les performances de<br />
<strong>WLAN</strong><br />
Bien que les performances (débit réel) de <strong>WLAN</strong> soit directement liée à la probabilité<br />
d’interférences, d’autres paramètres <strong>entre</strong> aussi en ligne de compte. Il s’agit<br />
principalement des techniques de modulations <strong>et</strong> des puissances d’émissions utilisées<br />
par les dispositifs. C<strong>et</strong>te aspect de la coexistence est traité en partie avec l’aide d’un<br />
simulateur dans le modèle théorique, car il est difficile d’obtenir des résultats avec des<br />
idées, du papier <strong>et</strong> un crayon.<br />
88
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
4.4 Evaluation des performances réelles de <strong>WLAN</strong><br />
Le critère d’évaluation des performances est le débit réel lors d’une communication.<br />
Le débit réel est le débit fournit par la couche MAC, il ne prend donc pas en compte<br />
les entêtes des niveaux 1 <strong>et</strong> 2 du protocole <strong>802.11</strong>b. Le norme ne mentionne pas le<br />
débit réel, mais donne le débit brut de la communication qui peut être de 11, 5,5, 2 où<br />
1 Mbps. Le calcul pour passer du débit brut au débit réel au niveau MAC pour<br />
CSMA/CA est le suivant :<br />
Figure 54 : Envoi <strong>et</strong> acquittement d’une trame avec CSMA<br />
La durée d’une trame (t sur la Figure 54) dépend du nombre de bytes d’information<br />
transmis à la couche MAC <strong>et</strong> du débit utilisé :<br />
N MAC Header FCS PLCP eamble PLCP Header<br />
t<br />
⎛ 8 ⋅(<br />
+ _ + ) _Pr + _<br />
=<br />
⎞<br />
⎜<br />
D<br />
⎟+<br />
⎝<br />
<strong>WLAN</strong> ⎠<br />
DPLCP<br />
Équation 9<br />
N : Nombre de byte d’information<br />
MAC_header : 30 bytes<br />
FCS : 4 bytes<br />
PLCP_Preamble : 144 bits<br />
PLCP_Header : 48 bits<br />
D <strong>WLAN</strong> : débits <strong>802.11</strong>b, 1, 2, 5,5 où 11 Mbps<br />
D PLCP : 1 Mbps<br />
89
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
L’acquittement est calculé pour un débit de 2 Mbps, c<strong>et</strong>te valeur correspond aux<br />
résultats donnés par les analyseurs de protocoles :<br />
t<br />
ack<br />
8⋅N<br />
=<br />
ack<br />
+ PLCP_Preamble+<br />
PLCP_<br />
header<br />
= 248μs<br />
D<strong>WLAN</strong><br />
Équation 10<br />
La fenêtre de contention varie en fonction du nombre de collisions sur le canal. Pour<br />
c<strong>et</strong>te étude, il est admis que les communications des dispositifs <strong>WLAN</strong> n’engendre pas<br />
de collisions. Les simulations <strong>et</strong> les mesures effectuées traite toutes du cas simple où<br />
les réseaux <strong>WLAN</strong> sont constitués de deux stations. La fenêtre de contention est donc<br />
minimal, ce qui pour <strong>802.11</strong>b DSSS donne CW=31.<br />
Le temps nécessaire pour ém<strong>et</strong>tre une trame <strong>et</strong> pour l’acquitter (T) vaut :<br />
T = t+<br />
SIFS+<br />
tack+<br />
2 ⋅DIFS+<br />
1010 ⋅<br />
−6⋅CW<br />
Équation 11<br />
Le débit réel fournit par <strong>802.11</strong> est le rapport <strong>entre</strong> la quantité d’information échangée<br />
<strong>et</strong> le temps T :<br />
<strong>Dr</strong>eel=<br />
T N<br />
Équation 12<br />
Figure 55 : Tableau du débit réel de <strong>WLAN</strong> <strong>802.11</strong>b<br />
90
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Lorsque lors d’une communication des trames sont erronées par Blu<strong>et</strong>ooth, elles ne<br />
sont pas acquittées. L’ém<strong>et</strong>teur est donc obligé de les réenvoyer. Le réenvoi d’une<br />
trame double le temps nécessaire pour ém<strong>et</strong>tre une trame, car il faut répéter<br />
l’ensemble de la procédure (data+SIFS+ack+DIFS+backoff(CW)+DIFS). La loi<br />
géométrique montre que le débit est réel est directement proportionnel à la probabilité<br />
qu’une trame soit erronée :<br />
μ = 1<br />
1 − p<br />
Équation 13 [PAT]<br />
p : probabilité qu’une trame soit erronée<br />
μ est l’espérance mathématique, ce qui veut dire qu’il s’agit du nombre moyen de<br />
trame qu’il faudra envoyer avant que l’une d’elles soit correctement transmise. En<br />
considérant que chaque trame à une probabilité d’être erronée, ont obtient la formule<br />
suivante pour le calcul du débit réel :<br />
<strong>Dr</strong>eel<br />
D= = (1−<br />
p)<br />
⋅D<br />
p<br />
T N<br />
reel=<br />
(1−<br />
) ⋅<br />
μ<br />
Équation 14<br />
91
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
A partir de l’Équation 8 <strong>et</strong> de l’Équation 14, il est possible de déterminer le débit réel<br />
de <strong>WLAN</strong> en présence de Blu<strong>et</strong>ooth en fonction de la dimension des trames<br />
échangées :<br />
B<br />
D=<br />
T N ⋅<br />
⎛<br />
⎜1<br />
−<br />
⎝<br />
<strong>WLAN</strong><br />
+ ( B<br />
B<br />
Blu<strong>et</strong>ooth<br />
ISM<br />
Équation 15<br />
−1)<br />
⎞<br />
⎟<br />
⎠<br />
1+<br />
t⋅<br />
fhop<br />
Figure 56 : Débit réel en présence de Blu<strong>et</strong>ooth<br />
92
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
93
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
5 Mesures,<br />
simulations <strong>et</strong><br />
solutions existantes<br />
94
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
5.1 Mesures <strong>et</strong> résultats<br />
Les constructeurs utilisant Blu<strong>et</strong>ooth ou <strong>WLAN</strong> ont rapidement pris conscience du<br />
problème posé par la cohabitation des deux technologies. Certaines <strong>entre</strong>prises ont<br />
donc étudié, simulé <strong>et</strong> mesuré les pertes de performances des dispositifs lorsqu’ils<br />
communiquent simultanément. L’IEEE se préoccupe aussi du problème de la<br />
coexistence. Le groupe <strong>802.11</strong>.2 est chargé de trouver une solution.<br />
Il serait trop long de faire ici la liste de toute les mesures <strong>et</strong> simulations <strong>entre</strong>prises<br />
dans l’étude de la coexistence. La suite de c<strong>et</strong>te section ne traite donc que des<br />
documents les plus pertinents.<br />
5.1.1 Simulations<br />
En 1998, Greg Ennis pose bien le problème de la cohabitation dans un document<br />
appelé « Impact of Blu<strong>et</strong>ooth on <strong>802.11</strong> Direct Sequence Wireless LANs » [GESIMP].<br />
Ce document donne les résultats d’une simulation, mais donne peut de renseignement<br />
quant à la manière dont on été obtenu les résultats. Les résultats portent sur les<br />
dégradations de débits en fonction de la taille des paqu<strong>et</strong>s envoyés.<br />
Fin 1998, Jim Zyren propose une amélioration du modèle de Greg Ennis ; « Extension<br />
of Blu<strong>et</strong>ooth and <strong>802.11</strong> Direct Sequence Interference Model » [JZNEXT]. Ce<br />
document est plus détaillé que le précédent. Les pertes de débit résultant de la<br />
simulation sont d’environ 18% pour le communication à 5,5 Mbps <strong>et</strong> 16% à 11 Mbps<br />
dans le cas d’une forte utilisation de Blu<strong>et</strong>ooth.<br />
Juin 1999, Jim Zyren affine encore son étude de la coexistence en publiant ;<br />
« Reliability of IEEE <strong>802.11</strong> Hi Rate DSSS <strong>WLAN</strong>s in a High Density Blu<strong>et</strong>ooth<br />
Environment ». Différentes applications <strong>WLAN</strong>s sont testées, comme par exemple<br />
l’e-mail ou la téléphonie. La principale conclusion de ce document est qu’une fortes<br />
densité de dispositifs Blu<strong>et</strong>ooth dans le même espace que <strong>WLAN</strong> nuit fortement aux<br />
performances des applications.<br />
95
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
5.1.2 Mesures<br />
Les documents présentés dans la partie simulations ne font pas mentions de mesures.<br />
En eff<strong>et</strong>, il est difficile de m<strong>et</strong>tre en place des mesures reflétant une utilisations<br />
générale de Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong>, cela en raison de l’influence de l’environnement<br />
(structure des locaux, mobilier …). La compagnie Mobilian travaillant sur la<br />
technologie sans-fil a pourtant publié une mesure [MOBSOP] simple concernant les<br />
performances de <strong>WLAN</strong> <strong>802.11</strong>b en cas d’interférence avec Blu<strong>et</strong>ooth. C<strong>et</strong>te mesure a<br />
été réalisée dans le but de régler le problème de la coexistence en commercialisant des<br />
cartes réseaux utilisant les technologies Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong> dans le même dispositif.<br />
Figure 57 : Description de la mesure<br />
Le but de la mesure est de connaître la perte de débit de la communication <strong>WLAN</strong> en<br />
fonction de la distance en les deux stations. C<strong>et</strong>te mesure a donné des résultats<br />
intéressants.<br />
96
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Figure 58 : Résultat de la mesure (source : Mobilian Corp.)<br />
Les dégradations deviennent très importante lorsque la distance <strong>entre</strong> les stations<br />
augmente <strong>et</strong> que le signal est perturbé par un dispositif Blu<strong>et</strong>ooth.<br />
5.2 Solutions<br />
Il existe plusieurs possibilités pour perm<strong>et</strong>tre la cohabitation des technologies<br />
Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong> <strong>802.11</strong>b. Ces possibilités peuvent être divisée en deux catégories :<br />
1. Les solutions utilisant la couche MAC, avec des techniques comme<br />
Adaptive Hopping (AFH), Adaptive Power Control ou MAC-level<br />
Switching.<br />
2. Les solutions logiciels, ces techniques sont appelées <strong>Dr</strong>iver-level<br />
Switching.<br />
La possibilité pour l’utilisateur de choisir manuellement quel techonologie constitue<br />
une troisième catégorie. C<strong>et</strong>te méthode, appelée Manual Switching, donne à l’utilisateur<br />
la possibilité de sélectionner lui-même quelle technologie il désire employer par<br />
exemple lorsqu’il utilise son ordinateur.<br />
Les solutions se différencient aussi par leur interaction avec les technologies avec<br />
lesquels elles doivent gérer les interférences. Ainsi une distinction est faite <strong>entre</strong><br />
97
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
solution collaborative <strong>et</strong> non-collaborative. Adaptive Frenquency Hopping est une<br />
solution non-collaborative car elle se comporte indépendement du système avec lequel<br />
elle doit gérer la cohabitation.<br />
5.2.1 Adaptive Frequency Hopping (AFH)<br />
AFH est une métode perm<strong>et</strong>tant de limiter les interférences <strong>entre</strong> Blu<strong>et</strong>ooth <strong>et</strong><br />
d’autres dispositifs 1 travaillant dans la même bande de fréquence (ISM). Il s’agit pour<br />
les dispositifs Blu<strong>et</strong>ooth de détecter les canaux subissant des interférences <strong>et</strong> de<br />
sélectionner uniquement les canaux non-perturbés pour la transmission. C<strong>et</strong>te<br />
opération nécessite quatre sous-opérations :<br />
• Classification des canaux (Channel Classification)<br />
C<strong>et</strong>te phase perm<strong>et</strong> de sélectionner les canaux qui seront utilisés pour la<br />
transmission. Pour l’évaluation de la qualité d’un signal, un récepteur<br />
Blu<strong>et</strong>ooth peut utiliser RSSI 2 , utiliser une procédure particulière ou encore se<br />
baser sur les HEC ou CRC des paqu<strong>et</strong>s reçus. Les canaux sont ensuite séparés<br />
en deux catégories ; bon ou mauvais (bad or good). Les canaux identifiés<br />
comme bon pourront être utilisé pour former une nouvelle séquence.<br />
• Gestion des liaisons (Link Management)<br />
L’état des canaux doit être transmis par chacun des dispositifs vers le maître<br />
afin qu’il détermine la nouvelle séquence de hops qu’il va appliquer. Le maître<br />
utilise ensuite le protocole de gestion liaison, appelé LMP (Link Manager<br />
Protocol) pour transm<strong>et</strong>tre aux autres dispositifs les canaux sur les-quels ils<br />
devront ém<strong>et</strong>tre.<br />
• Modification de la séquence des hops (Hop Sequence Modification)<br />
Lorsque tout les dispositif ont reçus la liste des canaux, ils doivent modifier<br />
leur séquence de hops <strong>et</strong> se resynchroniser avec le maître.<br />
• Maintenance des canaux (Channel Maintenance)<br />
L’ensemble de l’opération est répété périodiquement afin de s’adapter à<br />
d’éventuel changement des perturbations sur la bande passante.<br />
1 Principalement Wireless LAN <strong>802.11</strong>b<br />
2 Receiver Signal Strength Indicator, perm<strong>et</strong> à un dispositif Blu<strong>et</strong>ooth de connaître la puissance de<br />
réception<br />
98
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Une normalisation de AFH est prévue pour le milieu de l’année 2003. La spécification<br />
restreindra le nombre minimum de canaux sélectionnable à 15. C<strong>et</strong>te proposition<br />
émane de l’autorité américaine chargée des communications, appelée FCC (Federal<br />
Communication Commission). De son coté, l’ETSI propose que le nombre minimum<br />
de canaux soit de 20. La question reste en encore en suspend à l’heure actuelle.<br />
Figure 59 : Spectre – Interférence <strong>entre</strong> Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong> <strong>802.11</strong>b<br />
La figure ci-dessus montre l’eff<strong>et</strong> bénéfique de AFH lorsque les fréquences des<br />
dispositifs Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong> se chevauchent. Le canal Blu<strong>et</strong>ooth qui interférait avec<br />
le canal <strong>WLAN</strong> est remplacé par un canal qui ne subit pas (ou très peu) d’interférence.<br />
Ce cas se présente lorsque le nombre de canaux minimum est atteint. Dans le cas ou le<br />
nombre de bon canaux est encore suffisant, le canal perturbé est simplement r<strong>et</strong>iré de<br />
la liste des canaux utilisables <strong>et</strong> il n’est pas nécessaire de le remplacer.<br />
Le principal avantage de AFH est qu’il s’adapte automatiquement en cas d’interférence<br />
avec un signal de bande étroite. En eff<strong>et</strong>, à un canal perturbé sera substitué un canal<br />
de bonne qualité. Le fait que seul les meilleurs canaux soient utilisés perm<strong>et</strong> d’obtenir<br />
99
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
un BER 1 moins élevé <strong>et</strong> par conséquence un débit optimum. De plus les mécanismes<br />
de contrôle de la puissance utilisé par AFH réduise de manière significative la<br />
puissance d’émission des équipements.<br />
En plus des eff<strong>et</strong>s bénéfiques sur la qualité des transmissions <strong>entre</strong> dispositifs<br />
Blu<strong>et</strong>ooth, c<strong>et</strong>te solution améliore énormément la qualité des transmissions <strong>entre</strong><br />
dispositifs <strong>WLAN</strong>. En eff<strong>et</strong>, les interférences avec <strong>WLAN</strong> sont automatiquement<br />
écartée par le processus de AFH qui ne conserve que les canaux non-perturbés.<br />
5.2.2 <strong>Dr</strong>iver-level Switching<br />
Avec la méthode du <strong>Dr</strong>iver-level Switching, la gestion des communications <strong>entre</strong> les<br />
deux types de dispositifs est réalisée par les hautes couches des protocoles. Les deux<br />
protocoles communiquent <strong>entre</strong> elles pour obtenir le droit d’ém<strong>et</strong>tre. Le <strong>Dr</strong>iver-level<br />
Switching n’est de ce fait applicable que lorsque les deux types de dispositifs à gérer<br />
appartiennent à une même station.<br />
Pour empêcher les dispositifs de communiquer simultanément, il s’agit d’en désactiver<br />
un pendants que le second est en train d’ém<strong>et</strong>tre ou de recevoir des données. Cela<br />
peut être réaliser facilement en utilisant le mode DOZE pour le <strong>WLAN</strong> <strong>et</strong> les modes<br />
SNIFF, HOLD ou PARK pour Blu<strong>et</strong>ooth.<br />
Figure 60 : Schéma conceptuel du <strong>Dr</strong>iver-level Switching (source : Mobilian)<br />
1 Bit Error Rate, taux d’erreur par bit<br />
100
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Le <strong>Dr</strong>iver-level Switching est une méthode relativement facile à m<strong>et</strong>tre en place.<br />
Cependant elle impose des limites difficilement supportable pour certaines<br />
applications. La commutation d’un système à un autre n’étant pas assez rapide, il est<br />
en impossible de gérer simultanément une liaison SCO avec Blu<strong>et</strong>ooth <strong>et</strong> le transfert<br />
de donnée par le biais du réseau <strong>WLAN</strong>. Par exemple, un utilisateur portant heads<strong>et</strong><br />
Blu<strong>et</strong>ooth (connecté à son laptop) est dans l’impossibilité d’utiliser une connexion<br />
<strong>WLAN</strong> pour téléphoner sur IP. Malgré c<strong>et</strong>te inconvénient, bon nombre de<br />
constructeur travail sur le développement d’une solution allant dans c<strong>et</strong>te direction.<br />
5.2.3 MAC-level Switching<br />
MAC-level Switching reprend le même principe que <strong>Dr</strong>iver-level Switching. Mais<br />
contrairement à <strong>Dr</strong>iver-level Switching qui contrôlait les communications dans les<br />
couches supérieures des deux protocoles, MAC-level Switching gère la coexistence au<br />
niveau de la couche MAC.<br />
Le fait de travailler au niveau MAC rend les commutations d’un système à l’autre<br />
beaucoup plus précise. La méthode MAC-level Switching offre donc des<br />
performances supérieures à celle de <strong>Dr</strong>iver-level Switching. Cependant, c<strong>et</strong>te<br />
amélioration des performances ne perm<strong>et</strong> pas de surmonter le problème posé par une<br />
liaison SCO avec Blu<strong>et</strong>ooth.<br />
5.2.4 Manual Switching<br />
Le véritable avantage du Manual Switching est qu’il est très simple à m<strong>et</strong>tre en œuvre ;<br />
il s’agit simplement de perm<strong>et</strong>tre à l’utilisateur de choisir si il désire utiliser Blu<strong>et</strong>ooth<br />
ou <strong>WLAN</strong>. Le fait d’avoir à choisir en l’une ou l’autre des technologies rend c<strong>et</strong>te<br />
solution mal-adaptée à certaines applications. Il n’est par exemple plus possible de se<br />
connecter à Intern<strong>et</strong> avec <strong>WLAN</strong> <strong>et</strong> d’utiliser parallèlement à cela une souris<br />
Blu<strong>et</strong>ooth sans-fil.<br />
101
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
102
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6 Modèle théorique<br />
103
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.1 Objectif<br />
Le but du modèle théorique est de déterminer les pertes de débit d’une transmission<br />
<strong>WLAN</strong> <strong>802.11</strong>b lors de la cohabitation avec Blu<strong>et</strong>ooth. C<strong>et</strong>te modélisation se divise en<br />
plusieurs étapes :<br />
1. Modèle de propagation de l’onde électromagnétique<br />
Il s’agit de déterminer quel est le comportement des signaux envoyés par les<br />
ém<strong>et</strong>teurs. L’objectif de ce modèle est d’être en mesure de déterminer la<br />
puissance d’un signal en fonction de sa position par rapport au point où il a<br />
été émis.<br />
P= f( P0 , d)<br />
ou L= f(d)<br />
Équation 16<br />
P : Puissance du signal [W] ou [dBm]<br />
P 0 : Puissance d’émission [W] ou [dBm]<br />
L : Perte de puissance du signal [dB]<br />
P : position relative par rapport à l’ém<strong>et</strong>teur [m]<br />
2. Modèle d’interférence<br />
En connaissant la puissance des signaux émis par les dispositifs Blu<strong>et</strong>ooth<br />
<strong>et</strong> <strong>WLAN</strong> en fonction de leur distance par rapport à l’ém<strong>et</strong>teur, il est<br />
possible de connaître le rapport signal sur interférence (S/I) <strong>entre</strong> les deux<br />
signaux dans n’importe quel point de l’espace. Le modèle d’interférence<br />
doit perm<strong>et</strong>tre de déterminer la probabilité d’erreur par bit P e en fonction<br />
du S/I sur le récepteur.<br />
P e=<br />
f( S/<br />
I)<br />
= f(<br />
P<strong>WLAN</strong>,<br />
PBT)<br />
= f(<br />
L<strong>WLAN</strong>,<br />
LBT,<br />
d<strong>WLAN</strong>,<br />
dBT)<br />
Équation 17<br />
P e : Probabilité d’erreur par bit (BER) [-]<br />
S/I : Rapport signal sur interférence[dB]<br />
P <strong>WLAN</strong> : Puissance du signal <strong>WLAN</strong> [W] ou [dBm]<br />
P BT : Puissance du signal Blu<strong>et</strong>ooth [W] ou [dBm]<br />
104
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
L <strong>WLAN</strong> : Perte de puissance du signal <strong>WLAN</strong> [dB]<br />
L BT : Perte du puissance signal Blu<strong>et</strong>ooth [dB]<br />
3. Modèle du débit<br />
A partir du taux d’erreurs par bit, il est possible de calculer le débit réel<br />
d’une communication <strong>entre</strong> deux dispositifs <strong>WLAN</strong>.<br />
D=<br />
f( Pe<br />
, N)<br />
Équation 18<br />
D : Débit [Mbps]<br />
P e : Probabilité d’erreur par bit [-]<br />
N : Nombre de bit par trame [-]<br />
En suivant les étapes du modèle théorique, il est donc possible de déterminer le débit<br />
d’une communication <strong>WLAN</strong> lorsqu’elle est perturbée par une communication <strong>entre</strong><br />
dispositifs Blu<strong>et</strong>ooth. En réalité, le nombre de paramètres <strong>et</strong> résultats de chaque<br />
modèle est plus important que ce qui est décrit ci-dessus. Ces paramètres <strong>et</strong> résultats<br />
additionnels perm<strong>et</strong>tent d’obtenir une simulation plus précise, tenant compte de<br />
différents cas d’utilisation.<br />
6.2 Modèle de propagation des ondes électromagnétiques<br />
6.2.1 Généralités<br />
La propagation des ondes électromagnétiques est décrite par les équations de Maxwell.<br />
Grâce à Maxwell, il est possible de déterminer les caractéristiques d’un signal<br />
électromagnétique en n’importe quel point de l’espace. Cependant, dans les cas réels<br />
d’utilisation, le calcul à partir des équations de Maxwell s’avère très compliqué. En<br />
eff<strong>et</strong>, la terre est un environnement hostile à la bonne propagation des ondes<br />
électromagnétiques. Sur terre, la propagation d’une onde électromagnétique dépend<br />
d’un grand nombre de facteurs. Il s’agit donc de trouver un modèle perm<strong>et</strong>tant de<br />
calculer plus simplement la valeur d’un signal en fonction de sa distance par rapport à<br />
105
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
l’ém<strong>et</strong>teur <strong>et</strong> de sa puissance d’émission. Le modèle de propagation n’est donc pas<br />
exact, mais doit cependant avoir une précision suffisante. La précision du modèle<br />
dépend des hypothèses émises concernant l’environnement dans lequel se propage le<br />
signal <strong>et</strong> les antennes utilisées par les dispositifs.<br />
6.2.2 Hypothèse n°1 : Caractéristiques des antennes<br />
La puissance des antennes utilisées dépend des réglementations en vigueur dans les<br />
états. Chaque fabricant de carte <strong>WLAN</strong> ou Blu<strong>et</strong>ooth spécifie la puissance d’émission<br />
de l’antenne utilisée. C<strong>et</strong>te puissance n’est, dans la plupart des cas, pas la puissance<br />
réellement émise mais la puissance EIRP (Effective Isotropic Radiated Power). La<br />
puissance EIRP est la puissance considérée pour une émission isotropique. C’est-àdire<br />
que les ondes électromagnétiques se propagent autours de l’antenne de manière<br />
uniforme dans toutes les directions. En réalité, ça n’est pas tout à fait le cas.<br />
Figure 61 : Différence <strong>entre</strong> propagation isotropique <strong>et</strong> non-isotropique<br />
(source : rf.rfglobaln<strong>et</strong>.com)<br />
La figure ci-dessus montre la différence <strong>entre</strong> une antenne dont le rayonnement est<br />
isotropique <strong>et</strong> le rayonnement qui pourrait être celui d’une antenne réelle. Une antenne<br />
non-isotropique ém<strong>et</strong> plus de puissance dans certaines directions. C<strong>et</strong>te particularité<br />
des antennes non isotropiques est exprimée par une valeur appelée le gain de l’antenne<br />
106
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
g i (Θ), où Θ représente la direction dans la quel se propage l’onde électromagnétique<br />
par rapport à l’antenne. Le gain d’une antenne perm<strong>et</strong> de calculer la puissance EIRP<br />
d’une antenne à partir de sa puissance d’émission :<br />
EIRP=<br />
g<br />
P<br />
π<br />
i<br />
4 0<br />
Équation 19<br />
P 0 : Puissance de l’antenne [W]<br />
La densité de puissance dans le cas d’une émission isotropique est donnée par la<br />
formule suivante :<br />
PD<br />
= P<br />
4πr<br />
0<br />
2<br />
Équation 20<br />
P D : Densité de puissance [W/m 2 ]<br />
r : distance <strong>entre</strong> le point considérer <strong>et</strong> l’antenne [m]<br />
Dans le cas d’une antenne non isotropique la densité de puissance doit être<br />
reconsidérée en fonction du gain g i (Θ) :<br />
P EIRP g P<br />
D = 4π r<br />
= r<br />
0<br />
i<br />
2<br />
(4π<br />
)<br />
2<br />
Équation 21<br />
107
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Le fonctionnement d’un récepteur suit un peu près les même règles que celui d’un<br />
récepteur. Le gain d’un récepteur g R perm<strong>et</strong> de déterminer la puissance effectivement<br />
reçue par un récepteur :<br />
P = g<br />
R<br />
g<br />
P<br />
πr<br />
0<br />
i λ2<br />
( 4 )<br />
2<br />
Équation 22<br />
P R : Puissance reçue par le récepteur [W]<br />
λ : longueur d’onde du signal [m]<br />
La perte de puissance d’un signal dans le vide peut être tiré de l’Équation 22, elle<br />
correspond au rapport <strong>entre</strong> la puissance de réception <strong>et</strong> la puissance d’émission :<br />
( λ ) 2<br />
L=<br />
4πr<br />
Équation 23<br />
L : Perte de puissance [W]<br />
En tenant compte des gains du récepteur <strong>et</strong> de l’ém<strong>et</strong>teur, la perte obtenue s’écrit de la<br />
manière suivante :<br />
( λ ) 2<br />
L=<br />
P<br />
= gRgi<br />
P0 4πr<br />
Équation 24<br />
108
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
En général lorsqu’il s’agit de travailler avec des puissances, il est préférable de travailler<br />
avec des échelles logarithmiques. L’Équation 24 devient alors :<br />
L = −10log<br />
⎛ P ⎞<br />
⎜ 10log<br />
P<br />
⎟=−<br />
⎝ 0 ⎠<br />
( gR) −10log( gi) −20log( λ )<br />
Équation 25<br />
4πr<br />
Les dispositifs destinés à être utilisés à l’intérieur des bâtiments sont en général basés<br />
sur des antennes qui ont un comportement proche d’une antenne isotropique. De ce<br />
fait le gain des antennes n’est que rarement fourni par les constructeurs. Le modèle<br />
théorique pour la propagation du signal électromagnétique considérera donc les<br />
antennes comme étant isotropiques. La formule pour la propagation d’une onde<br />
électromagnétique dans l’espace 1 provient de l’Équation 25 :<br />
( λ )<br />
L = −10log<br />
⎛ P ⎞<br />
⎜ 20log<br />
P<br />
⎟=−<br />
⎝ 0 ⎠ 4πr<br />
Équation 26<br />
Dans le cas d’études plus détaillées ou de mesure avec des antennes particulières, il<br />
s’agira d’être attentif au gain <strong>et</strong> de se référer à l’Équation 25 dans le cas ou l’antenne<br />
est non isotropique.<br />
6.2.3 Hypothèse n°2 : Longueur d’onde<br />
La seconde hypothèse concerne la longueur d’onde des technologies utilisées. La<br />
bande de fréquence utilisée par les technologies Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong> <strong>802.11</strong>b s’étant<br />
de 2,4 à 2,4835GHz. Afin de simplifier les calculs, les pertes de puissance sont<br />
calculées à partir d’une fréquence moyenne. La fréquence moyenne est la moyenne<br />
arithmétique <strong>entre</strong> la fréquence minimum <strong>et</strong> maximum.<br />
2 ,4+<br />
2,4835<br />
= ⋅10<br />
2,442[ ]<br />
2<br />
9 GHz<br />
fmoy =<br />
Équation 27<br />
1 Vide, pas d’atmosphère<br />
109
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
La longueur d’onde λ est calculée à partir de la fréquence moyenne par la formule<br />
suivante, où v est la vitesse de la lumière :<br />
λ =<br />
3108<br />
0,1224[ m]<br />
f v ⋅<br />
= =<br />
moy 2,44210 ⋅<br />
9<br />
Équation 28<br />
C<strong>et</strong>te approximation induit une erreur inférieure à 2% <strong>entre</strong> les bords <strong>et</strong> le milieu de la<br />
bande de fréquence. C<strong>et</strong>te erreur est acceptable dans le cadre de ce modèle, elle ne<br />
sera donc pas prise en compte dans les calculs.<br />
6.2.4 Hypothèse n°3 : Conditions atmosphériques<br />
Jusqu’à présent le modèle considère que les ondes se déplacent dans le vide. Sur terre<br />
la réalité est différente ; les ondes évoluent dans l’atmosphères, voir dans la ionosphère<br />
ou dans la troposphère pour certaines applications 1 . La matière contenue dans<br />
l’atmosphère influe sur la propagation d’une onde électromagnétique. Ainsi la perte de<br />
puissance dépend des conditions atmosphériques. Cependant dans le cadre de c<strong>et</strong>te<br />
étude, les conditions atmosphériques jouent un rôle secondaire tant leur eff<strong>et</strong> est<br />
minime. Ainsi pour des conditions normales d’utilisation (20°C, 100kPa, 7,5g<br />
d’eau/m 3 ), les pertes enregistrée sont d’environ 0,15 dB/km [Annexe1].<br />
Les conditions atmosphériques ont donc une influence de très loin inférieure à 1%. Il<br />
est donc raisonnable de considérer que les conditions atmosphériques n’ont aucune<br />
influence sur la propagation des ondes électromagnétiques.<br />
6.2.5 Hypothèse n°4 : Mobilité<br />
Les stations ém<strong>et</strong>trices <strong>et</strong> réceptrices sont considérées comme fixe. C<strong>et</strong>te hypothèse<br />
perm<strong>et</strong> de ne pas prendre en compte l’eff<strong>et</strong> Doppler. C<strong>et</strong>te approximation est peu<br />
restrictive car la plupart des stations d’un réseau <strong>WLAN</strong> ne se déplace pas. En<br />
1 Mais Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong> sont des technologies destinées à travailler essentiellement dans un milieu<br />
atmosphérique.<br />
110
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
imaginant que le possesseur d’un laptop se déplace pendant que son ordinateur<br />
communique, il serait surprenant que la vitesse de c<strong>et</strong> utilisateur au sein d’un bâtiment<br />
dépasse quelques km/h (hormis peut-être ascenseur nouvelle génération). Dans ces<br />
conditions, l’eff<strong>et</strong> Doppler a une influence infime sur les résultats, il peut<br />
raisonnablement être négligé.<br />
6.2.6 Hypothèse n°5 : Réflexions<br />
Les réflexions jouent un rôle très important dans ce modèle. En eff<strong>et</strong>, l’immense<br />
majorité des réseaux locaux sont réalisés à l’intérieur d’un bâtiment. Dans un espace<br />
restreint, les ondes se reflètent contre les parois. Les ondes réfléchies, déphasées par le<br />
chemin qu’elles ont parcouru, viennent se superposer au signal original. Le signal reçu<br />
est donc perturbé par les réflexions.<br />
Le signal original <strong>et</strong> les signaux réfléchis en se superposant produisent des<br />
interférences constructives ou destructives. Le but de ce document n’est pas de<br />
reprendre l’entier des théories sur la propagations des ondes électromagnétiques, mais<br />
il faut savoir que le fait que les interférences constructives <strong>et</strong> destructives produisent<br />
ce qui est couramment appelé des ondes stationnaires. C’est-à-dire qu’en un même<br />
point de l’espace la nature des interférences (constructives ou destructives) varie en<br />
fonction du temps.<br />
Figure 62 : Intensité du signal dans une pièce (source : [<strong>WLAN</strong>99])<br />
Bien qu’il soit envisageable de calculer l’eff<strong>et</strong> des réflexions dans un cas simple, c<strong>et</strong>te<br />
tâche devient quasi impossible dans les cas réels d’utilisation. En eff<strong>et</strong>, dans un local<br />
111
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
possédant du mobilier <strong>et</strong> une architecture particulière, modéliser ou mesurer<br />
l’ensemble des réflexions est un travail colossal. La Figure 62 montre l’intensité du<br />
signal sur l’ensemble d’un local. Les zones rouges (foncées) représentent les endroits<br />
où l’intensité est la plus importante.<br />
Pour contourner le problème lié aux réflexions, il est possible de considérer que<br />
l’intensité d’un signal en un endroit de l’espace (généralement l’endroit où est placé le<br />
récepteur) suit une certaine distribution. On parle alors de modèle statistique. Afin de<br />
simplifier le problème posé par les réflexions, la distribution de l’intensité du signal est<br />
considérée comme gaussienne.<br />
6.2.7 Résumé des hypothèses<br />
Hypothèse n°1<br />
Les dispositifs <strong>WLAN</strong> <strong>et</strong> Blu<strong>et</strong>ooth possèdent des antennes isotropiques.<br />
Hypothèse n°2<br />
La longueur d’onde λ est obtenu à partir de la moyenne arithmétique <strong>entre</strong> la<br />
fréquence minimum <strong>et</strong> maximum de la bande ISM 2,4 GHz.<br />
Hypothèse n°3<br />
Les conditions atmosphérique n’influence pas la propagation.<br />
Hypothèse n°4<br />
Les stations sont fixes.<br />
Hypothèse n°5<br />
L’intensité du champ électromagnétique dans l’espace considéré suit un modèle<br />
statistique.<br />
Les technologies Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong> <strong>802.11</strong>b utilisent une bande fréquence située à<br />
2,4 GHz. Le modèle proposé est valable pour ce type de fréquence, mais pas<br />
nécessairement pour toutes les fréquences. En eff<strong>et</strong>, des fréquences trop élevées<br />
(plusieurs dizaines de GHz) ou trop basse (quelques Hz) se propagent différemment<br />
lorsqu’elles évoluent sur terre.<br />
112
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.2.8 Description du modèle de propagation<br />
Les hypothèses émises concernant le modèle de propagation perm<strong>et</strong>tent de considérer<br />
l’Équation 26 comme valable pour le calcul de la puissance des signaux <strong>et</strong> d’en tirer la<br />
formule suivante :<br />
P<br />
= P<br />
[ dBm]<br />
0[ dBm]<br />
+<br />
Équation 29<br />
( λ )<br />
20log<br />
4πr<br />
Figure 63 : Modèle de propagation à 2,44 GHz<br />
113
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.3 Modèle d’interférence<br />
6.3.1 Description générale du modèle<br />
Pour calculer la probabilité d’erreur par bit P e , il s’agit de comparer les trames PLCP<br />
envoyées <strong>et</strong> reçue par deux dispositifs <strong>WLAN</strong> <strong>802.11</strong>b lorsque la transmission est<br />
perturbée par Blu<strong>et</strong>ooth.<br />
Figure 64 : Schéma du modèle d’interférence<br />
Les techniques de modulation utilisées par <strong>WLAN</strong> <strong>et</strong> Blu<strong>et</strong>ooth sont compliquées à<br />
m<strong>et</strong>tre en équation pour en tirer un modèle théorique satisfaisant. Il est préférable<br />
d’opter pour une simulation informatique. La simulation des interférences est donc<br />
réalisée sur la base des modules fournit par le logiciel Matlab. Matlab offre une librairie<br />
très complète de composants perm<strong>et</strong>tant de réaliser rapidement une simulation. Ainsi,<br />
114
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
la simulation des interférences est basée sur une simulation de M. Stuart McGarrity qui<br />
a entièrement implémenté le fonctionnement d’un dispositif <strong>WLAN</strong> <strong>802.11</strong>b. En y<br />
apportant les modifications perm<strong>et</strong>tant de simuler une transmission Blu<strong>et</strong>ooth sur le<br />
canal, une simulation très satisfaisante a été mise en place.<br />
La notion de probabilité d’erreur n’est très appropriée dans le cas d’interférences avec<br />
des dispositifs utilisant le frequency hopping (FHSS). En eff<strong>et</strong>, les erreurs produites<br />
par Blu<strong>et</strong>ooth apparaissent par paqu<strong>et</strong>s. Il se peut très bien que seule une partie des<br />
trames transmises contiennent des bits erronés. La probabilité d’erreur sur l’ensemble<br />
d’une communication n’est donc pas très appropriée pour l’étude de la coexistence. Il<br />
s’agit donc de définir d’autres valeurs perm<strong>et</strong>tant de diagnostiquer précisément les<br />
conséquences des interférences. En lieu <strong>et</strong> place de la probabilité d’erreur, le modèle<br />
d’interférence perm<strong>et</strong>tra de déterminer la taux de trames erronées (FER) <strong>et</strong> la<br />
probabilité d’erreur par trame erronées. En connaissant le nombre d’erreurs dans une<br />
trame lorsqu’elle erronée, cela perm<strong>et</strong>tra de proposer une solution appropriée<br />
lorsqu’une trame est fausse. Par exemple, si une trame ne contient que quelques bit de<br />
faux, un code correcteur est envisageable pour résoudre le problème de la coexistence.<br />
Ou, dans le cas ou la trame contiendra trop d’erreur, seule la répétition est possible.<br />
6.3.2 Hypothèses<br />
Comme pour le modèle de propagation, le modèle d’interférence se base sur un<br />
certain nombre d’hypothèses :<br />
• Les ondes électromagnétiques se propagent selon le modèle de<br />
propagation de la section 1.<br />
• Afin de simplifier le modèle, il est admis que les communications<br />
Blu<strong>et</strong>ooth sont unidirectionnelles. C’est-à-dire que les informations<br />
provenant d’une source ém<strong>et</strong>trice ne reçoivent pas de réponse.<br />
• Le signal transmis par les dispositifs <strong>WLAN</strong> est perturbé par un<br />
bruit gaussien. Le rapport signal sur bruit est un des paramètres de<br />
la simulations.<br />
115
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.3.3 Description de la simulation<br />
6.3.3.1 Description générale<br />
La simulation est entièrement réalisée sur Simulink. La librairie proposée par Simulink<br />
est impressionnante. Elle offre en eff<strong>et</strong> toutes sortes de blocks perm<strong>et</strong>tant la<br />
simulation d’outils de communication. De plus la compagnie MathWorks m<strong>et</strong> à<br />
disposition des simulations complètes <strong>et</strong> très bien élaborées. Les dispositifs <strong>WLAN</strong><br />
<strong>802.11</strong>b <strong>et</strong> Blu<strong>et</strong>ooth ont tout deux étés téléchargés à partir du site mathworks.com. La<br />
qualité de l’implémentation des dispositifs est excellente, <strong>et</strong> peu de modification y ont<br />
été apportées.<br />
Le simulation peut être divisée en trois parties distinctes ; la partie ém<strong>et</strong>teur <strong>et</strong><br />
récepteur <strong>WLAN</strong>, la simulation de la coexistence sur le canal (qui comprend les<br />
dispositifs Blu<strong>et</strong>ooth) <strong>et</strong> le traitement des résultats de la simulation.<br />
6.3.3.2 <strong>WLAN</strong><br />
Le dispositif <strong>WLAN</strong> utilisé dans c<strong>et</strong>te simulation reproduit le fonctionnement de la<br />
couche physique PMD. L’accent est donc porté sur les techniques de modulation <strong>et</strong><br />
démodulation. Le corps des trames est créé à partir d’un générateur aléatoire <strong>et</strong><br />
encapsulée dans une trame PCLP. Le préambule <strong>et</strong> l’entête sont ensuite modulés pour<br />
une transmission à 1 Mbps. La débit pour l’envoi du corps de la trame PLCP est un<br />
paramètre qui peut être configurer par l’utilisateur (1, 2, 5,5 ou 11 Mbps).<br />
Autre particularité du modèle ; les communications sont unidirectionnelles. En fait, les<br />
trames émises sont simplement démodulées par le récepteur. La procédure de<br />
synchronisation ou le CRC de l’entête ne sont pas vérifiés. En revanche (<strong>et</strong> cela est<br />
important dans le cadre de l’étude de la coexistence), la dimension des paqu<strong>et</strong>s, la<br />
puissance d’émission <strong>et</strong> le numéro de canal peuvent être modifiés.<br />
6.3.3.3 Canal <strong>et</strong> interférences<br />
Pour simuler l’interface aérien, un bruit gaussien est ajouté au signaux émis par les<br />
dispositifs <strong>WLAN</strong>. Des blocks perm<strong>et</strong>tant de régler le gain des signaux servent à<br />
exprimer les pertes de puissance dues à la distance <strong>entre</strong> ém<strong>et</strong>teur <strong>et</strong> récepteur.<br />
116
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Les signaux générés par les dispositifs Blu<strong>et</strong>ooth, après être passés dans un buffer 1 ,<br />
viennent s’additionner directement au canal utilisé par <strong>WLAN</strong>. Les émissions parasites<br />
ne sont pas paramétrables <strong>et</strong> cela est une source d'imprécision sur les résultats de la<br />
simulation.<br />
En eff<strong>et</strong>, les spécifications de la norme Blu<strong>et</strong>ooth garantissent que les émissions<br />
parasites ne dépassent pas –20 dB. A –20 dB (par rapport au signal Blu<strong>et</strong>ooth), les<br />
émissions parasites peuvent entraîner des erreurs sur les transmissions <strong>WLAN</strong>.<br />
Cependant ces émissions sont très difficilement quantifiables, il est illusoire de vouloir<br />
en faire un modèle précis (même empirique). Les émissions parasites ne sont donc pas<br />
prise en compte dans la simulation. C<strong>et</strong>te hypothèse peut paraître indélicate, mais en<br />
réalité il y a de fortes chances que les émissions parasites ne posent problèmes que<br />
pour des valeurs de signal sur interférence très faibles.<br />
6.3.3.4 Communications Blu<strong>et</strong>ooth<br />
La simulation d’une communication <strong>entre</strong> dispositifs Blu<strong>et</strong>ooth est basée sur<br />
l’hypothèse de la section 6.3.2. Il est donc admis que les dispositifs ne dialoguent pas<br />
directement <strong>entre</strong> eux mais qu’il s’agit en réalité de deux ém<strong>et</strong>teurs qui ne reçoivent<br />
aucune réponses. Ces dispositifs sont configurés de tel manière que leur émission<br />
ressemble à une communication normale.<br />
Blu<strong>et</strong>ooth utilise une technique TDD (Time Division Duplex) pour l’accès au canal,<br />
c’est à dire que le canal est partagé en time slot. Chaque dispositif est autorisé à<br />
ém<strong>et</strong>tre durant le où les time slot qui lui sont attribués Les blocks utilisés pour simuler<br />
un ém<strong>et</strong>teur Blu<strong>et</strong>ooth ont exactement le même fonctionnement. C’est à dire qu’ils<br />
ém<strong>et</strong>tent en même temps, sans se préoccuper des slots qui sont normalement alloués<br />
lors des communications. Pour contourner le problème, il s’agit de r<strong>et</strong>arder d’un slot le<br />
signal provenant de l’un des dispositifs.<br />
1 Matlab utilise des matrices pour la simulation. Ainsi une trame est représentée sous forme de vecteur<br />
dans une simulation Matlab. Lorsque que une trame Blu<strong>et</strong>ooth <strong>et</strong> une trame <strong>WLAN</strong> doivent être<br />
additionnées, il est indispensable que les vecteurs les représentant soient de même dimension. Pour<br />
réaliser cela, les trames Blu<strong>et</strong>ooth sont stockées à l’intérieur d’un buffer <strong>et</strong> réechantillonnées afin que<br />
leur dimension correspondent à celles des trames <strong>WLAN</strong>.<br />
117
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Figure 65 : Décalage d’un slot du signal du récepteur<br />
Bien que la séquence de hop des deux dispositifs Blu<strong>et</strong>ooth soit la même, le récepteur<br />
répond à une fréquence différente (hop suivant) de celle de la trame qu’il vient de<br />
recevoir. Pour simuler cela avec deux dispositifs qui ne communiquent pas réellement,<br />
il s’agit de modifier la séquence de hop de l’un des dispositifs. Pour cela, le signal<br />
fournit par le générateur de la séquence est décalé. Bien que c<strong>et</strong>te modification ne<br />
r<strong>et</strong>ranscrive pas exactement le déroulement réel d’une communication, elle néanmoins<br />
satisfaisante dans le cadre de c<strong>et</strong>te simulation.<br />
Figure 66 : Modification de la séquence de hop<br />
Ces modifications des blocks Blu<strong>et</strong>ooth existant perm<strong>et</strong>tent d’obtenir une simulation<br />
très proches des conditions réelles de fonctionnement.<br />
118
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.3.3.5 Traitement des résultats<br />
Les résultats <strong>et</strong> statistiques concernant la communication <strong>WLAN</strong> sont obtenus en<br />
comparant les trames envoyées <strong>et</strong> les trames reçues après démodulation. Le simulateur<br />
est en mesure de compter le nombre de trames erronées <strong>et</strong> le nombre de bit faux dans<br />
une trame erronée. Les différentes résultats fournis par le simulateur sont décrits plus<br />
précisément dans le mode d’emploi.<br />
6.3.3.6 Mode d’emploi<br />
Le simulateur a avant tout été conçu pour les besoins de l’étude de la coexistence <strong>entre</strong><br />
Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong>. Il n’a donc pas été jugé utile d’en faire un simulateur<br />
« convivial ». Le simulateur est donc un peu compliqué à prendre en main pour une<br />
personne non-initiée, l’interface homme-machine ayant été quelque peu négligée. Il n’a<br />
pas paru utile de réaliser une interface complète <strong>et</strong> bien conçue car la simulation de la<br />
coexistence est un problème très spécifique. Ce simulateur a vraisemblablement peu<br />
de chance d’être réutilisé dans le futur (cela n’enlevant rien à la qualité des<br />
informations qu'il donne). Voilà néanmoins un mode d’emploi qui perm<strong>et</strong>tra a un<br />
utilisateur éventuel une prise en main rapide du simulateur.<br />
Pré requis<br />
• Une version de Matlab disposant de Simulink version 5.0 (Matlab R13) ou<br />
ultérieure.<br />
• Que ceux pour qui Simulink est encore inconnu n’hésite pas à se référer à l’aide<br />
pour comprendre certain aspect du simulateur.<br />
• Une station relativement efficace.<br />
(Sur un PIII 450MHz, les simulations peuvent déjà durer plusieurs minutes.)<br />
Simulation<br />
a) Lancer le fichier blu<strong>et</strong>ooth_init.m<br />
(Sélection avec le bouton droit de la souris, puis run)<br />
b) Ouvrir le fichier Interference_Model_X<br />
(X étant le numéro de version, prendre le plus élevé)<br />
119
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Figure 67 : Simulateur<br />
c) Maintenant que le simulateur est ouvert, il s’agit de le paramétrer :<br />
1. Le block COEXISTENCE perm<strong>et</strong> de paramétrer les distances <strong>entre</strong> les<br />
dispositifs. La distance est exprimée par la perte d’intensité du signal (Path<br />
Loss). C<strong>et</strong>te valeur peut être calculée à partir de la distance <strong>entre</strong> dispositifs<br />
avec l’Équation 26 du modèle de propagation.<br />
Figure 68 : Paramétrage des pertes des différents dispositifs<br />
120
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
2. Affiche le nombre de trames transmises, le nombre de trames erronées <strong>et</strong> le<br />
pourcentage de trames erronées (FER).<br />
3. Indique le nombre moyen de bits erronés par trame erronée <strong>et</strong> le<br />
pourcentage de bit erronés par trame erronée.<br />
4. Indique le taux d’erreur par bit (BER) pour l’ensemble des bits envoyés.<br />
5. Ce block perm<strong>et</strong> de configurer les dispositifs <strong>WLAN</strong>. La reconfiguration des<br />
dispositifs <strong>WLAN</strong> ne nécessite pas de modification des blocks, sauf pour le<br />
débit. Si le débit est modifié, il faut répercuter c<strong>et</strong>te modification sur le<br />
buffer qui se situe dans le block COEXISTENCE.<br />
Figure 69 : Changement de la valeur du buffer<br />
Le buffer est chargé de faire correspondre le nombre de bit par pas de<br />
simulation émis par Blu<strong>et</strong>ooth <strong>et</strong> le nombre de bit émis par <strong>WLAN</strong>. Pour<br />
121
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
connaître le nombre de bit émis par <strong>WLAN</strong>, il faut lancer une simulation.<br />
Dans le cas où le nombre de bit émis par <strong>WLAN</strong> est différent de la taille du<br />
buffer, une erreur est signalée par le logiciel. Il faut alors remplacer la taille<br />
du buffer par celle indiquée sur l’entrée (voir Figure 69 : Changement de la<br />
valeur du buffer), puis relancer la simulation.<br />
6. Perm<strong>et</strong> de visualisé les spectres <strong>et</strong> les signaux émis par les dispositifs.<br />
Lorsque le block est activé (ON), la simulation est considérablement ralentie.<br />
Figure 70 : Spectre du signal reçu par le récepteur <strong>WLAN</strong><br />
6.3.4 Résultats de la simulation<br />
C<strong>et</strong>te section présente les simulations les plus pertinentes, ainsi que leurs résultats sous<br />
formes de graphiques. L’analyse des résultats est faite dans le chapitre 8 : Analyse <strong>et</strong><br />
solutions. Les résultats compl<strong>et</strong>s des simulations sont annexés en fin de rapport<br />
(Annexe 2).<br />
6.3.4.1 Transmission <strong>WLAN</strong> perturbée par un ém<strong>et</strong>teur Blu<strong>et</strong>ooth<br />
La première simulation effectuée suit le schéma de la Figure 71. Bien que cela ne<br />
corresponde pas à un cas d’utilisation réel, la communication <strong>entre</strong> les dispositifs<br />
<strong>WLAN</strong> n’est perturbée que par un seul ém<strong>et</strong>teur Blu<strong>et</strong>ooth. D’autres simulations,<br />
pour lesquels deux dispositifs Blu<strong>et</strong>ooth perturbent la communication <strong>entre</strong> deux<br />
dispositifs <strong>WLAN</strong> sont décrites dans la suite de ce document (section 6.3.4.2). Quoi<br />
qu’il en soit, les résultats obtenu lors des simulations <strong>et</strong> des mesures perm<strong>et</strong>trons par la<br />
122
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
suite d’extrapoler le comportement d’un réseau <strong>WLAN</strong> lorsqu’il est perturbé par<br />
plusieurs dispositifs.<br />
Figure 71 : Schéma de la simulation<br />
Une première simulation a été réalisée avec un ém<strong>et</strong>teur <strong>WLAN</strong> ém<strong>et</strong>tant à 1 W (30<br />
dBm) pour un débit de 11 Mbps. La dimension des PSDU a été fixée à 1024 bytes. La<br />
dimension des trames transmises influence le pourcentage de trame erronée, 1024<br />
bytes peut donc être considéré comme la dimension moyenne des trames. L’influence<br />
de la dimension des trames est traitée dans la suite de ce chapitre (sous la section<br />
6.3.4.2).<br />
Le type de liaison utilisé par l’ém<strong>et</strong>teur Blu<strong>et</strong>ooth joue un rôle important dans les<br />
problèmes de cohabitation. Dans le cas de c<strong>et</strong>te simulation, un cas particulièrement<br />
défavorable de liaison Blu<strong>et</strong>ooth a été simulé ; SCO avec des paqu<strong>et</strong>s HV1.<br />
123
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Figure 72 : Taux de trames erronées (P <strong>WLAN</strong> = 1W)<br />
La Figure 72 montre le pourcentage de trames erronées en fonction de la distance<br />
<strong>entre</strong> l’ém<strong>et</strong>teur <strong>et</strong> le récepteur <strong>WLAN</strong> <strong>et</strong> la distance <strong>entre</strong> l’ém<strong>et</strong>teur Blu<strong>et</strong>ooth <strong>et</strong> le<br />
récepteur <strong>WLAN</strong>.<br />
Une seconde simulation a été réalisée avec de puissance d’émission différentes. Le<br />
dispositif Blu<strong>et</strong>ooth ém<strong>et</strong> c<strong>et</strong>te fois-ci à 10 mW (10 dBm), alors que la puissance<br />
d’émission du dispositif <strong>WLAN</strong> est de 30 mW (15 dBm). La Figure 73 présente le<br />
pourcentage de trames erronées en fonction de la distances <strong>entre</strong> les ém<strong>et</strong>teurs <strong>WLAN</strong><br />
pour quatre distances <strong>entre</strong> ém<strong>et</strong>teur Blu<strong>et</strong>ooth <strong>et</strong> récepteur <strong>WLAN</strong> différentes.<br />
124
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Figure 73 Pourcentage de trames erronées<br />
Ces résultats sont intéressants. Ils montrent que, comme attendu, le taux de trames<br />
erronées dépend du rapport signal sur interférence (S/I).<br />
Figure 74 : FER en fonction du rapport S/I<br />
125
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.3.4.2 Influence de la dimension des trames<br />
Si les simulations réalisées précédemment perm<strong>et</strong>tent de déterminer l’influence des<br />
distances <strong>entre</strong> dispositifs dans la coexistence <strong>entre</strong> <strong>WLAN</strong> <strong>et</strong> Blu<strong>et</strong>ooth, elles ne<br />
prennent pas en compte l’influence que peut avoir la dimension des paqu<strong>et</strong>s sur le<br />
taux de trames erronées. Afin de déterminer l’impact de la dimension des trames, une<br />
simulation prenant en compte quatre trames de longueurs différentes a été mise en<br />
place. Les quatre longueurs de PSDU choisie pour la simulation sont les suivantes ;<br />
256, 512, 1024 <strong>et</strong> 2048 bytes. Les trames PSDU (niveau MAC) sont ensuite<br />
encapsulées dans une trame PLCP.<br />
Pour c<strong>et</strong>te simulation, deux dispositifs Blu<strong>et</strong>ooth viennent perturber la<br />
communication. Les deux dispositifs Blu<strong>et</strong>ooth communiquent <strong>entre</strong> eux au moyen<br />
d’une liaison SCO (paqu<strong>et</strong> HV1). La puissance d’émission des dispositifs est de 1 mW.<br />
Les deux dispositifs Blu<strong>et</strong>ooth sont placés à des distances différentes du récepteur<br />
<strong>WLAN</strong>, ainsi le premier dispositif est à 20 cm alors que le second est un 1 m. Ce<br />
scénario correspond de très près à certains cas réels d’utilisation, par exemple un<br />
utilisateur utilisant un heads<strong>et</strong> pour travailler sur ordinateur portable.<br />
Figure 75 : FER en fonction de la dimension des trames<br />
126
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.3.4.3 Influence du débit<br />
Les deux simulations suivantes (Influence du débit <strong>et</strong> Comportement en présence de<br />
plusieurs dispositifs Blu<strong>et</strong>ooth) ont été réalisée dans les conditions suivantes :<br />
• Puissance du dispositif <strong>WLAN</strong> : 30 mW<br />
• Puissance du(es) dispositif(s) Blu<strong>et</strong>ooth : 10 mW<br />
• Dimension des trames MAC : 1024 bytes<br />
Le débit d’une communication <strong>WLAN</strong> influence le taux d’erreur pour deux raisons ; le<br />
temps nécessaire pour transm<strong>et</strong>tre une trame <strong>et</strong> la robustesse de la technique de<br />
modulation face aux interférences. Plus le débit est faible, plus une trame sera longue à<br />
transm<strong>et</strong>tre <strong>et</strong> donc plus il y a de risques que Blu<strong>et</strong>ooth utilise un canal susceptible<br />
d’interférer pendant la transmission de la trame. Comme pour la simulation de<br />
l’influence de la dimension des trames, cela entraîne un taux d’erreur plus important.<br />
Figure 76 : FER en fonction du débit <strong>WLAN</strong><br />
Les résultats obtenus lors de c<strong>et</strong>te simulation perm<strong>et</strong>tent de comparer les différentes<br />
techniques de modulation.<br />
127
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.3.4.4 Comportement en présence de plusieurs dispositifs Blu<strong>et</strong>ooth<br />
Seule la communication <strong>entre</strong> deux dispositifs Blu<strong>et</strong>ooth à été simulée. La simulation<br />
de l’activité de 3, 4 ou plus de dispositifs aurait pu être réalisée, mais elle ne présente<br />
pas énormément d’intérêt. En eff<strong>et</strong>, si il s’agit de dispositifs appartenant au même<br />
picon<strong>et</strong> alors les résultats seront très proches d’une communication à deux dispositifs<br />
car les slots time sont occupés de la même manière, seules changent les distances <strong>entre</strong><br />
dispositifs. Dans le cas de dispositifs appartenant à des réseaux différents, <strong>et</strong> qui ne<br />
sont donc pas synchronisés, il est très difficile de déterminer un comportement général<br />
des dispositifs. Cependant les résultats obtenu avec deux dispositifs perm<strong>et</strong>trons de<br />
déterminer l’influence d’une telle situation avec une précision suffisante.<br />
Figure 77 : Comportement avec deux dispositifs Blu<strong>et</strong>ooth<br />
128
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.4 Modèle mathématique général du débit<br />
Comme tous le monde le sait, les réseaux téléinformatique fixe du type LAN ont un<br />
taux d’erreur par bit extrêmement bas 1 . Logiquement, ces réseaux ont un débit réel<br />
proche du débit théorique. En ce qui concerne les réseaux sans fil, le taux d’erreur<br />
peut être beaucoup plus élevé (peut arriver jusqu’à 10 -2 ). Ceci s’explique par le fait que<br />
l’air est rempli de parasite électromagnétique qui perturbe la communication.<br />
Pour des raisons de compréhension, il y a deux notions de bit :<br />
• Le bit physique qui représente le bit physiquement transmis,<br />
• le bit logique qui représente le bit utile à la couche avant un codage.<br />
Exemple : pour un codage FEC1/3, 1 bit logique devient 3 bits physique.<br />
Pour calculer le débit réel, quels paramètres doivent être connu :<br />
• le taux d’erreur par bit physique = p phy ,<br />
• taille de l’information en bit logique = i,<br />
• codage (FEC 1/3 ou 2/3 par exemple) = FEC,<br />
• taille de l’entête de la couche d’où on calcule le débit en bit logique = e,<br />
• débit binaire bien évidemment = D,<br />
• taille des paqu<strong>et</strong>s ACK <strong>et</strong> NACK en bit logique = c.<br />
6.4.1 Calcul du débit réel<br />
Un méthode pour trouver le débit réel est de considérer qu’un paqu<strong>et</strong> est bien arrivé<br />
uniquement si tous ces bits ont correctement été transmis. Pour que l'ém<strong>et</strong>teur sache<br />
que son paqu<strong>et</strong> est bien arrivé, le ACK doit aussi être correcte. Chaque paqu<strong>et</strong> doit<br />
bien évidemment être accompagné par un code détecteur d’erreurs 2 qui fait partie de<br />
l’entête.<br />
1 10 -9 pour les câbles de mauvaise qualité à 10 -12 pour de la fibre optique<br />
2 On le considère comme sûr à 100%<br />
129
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.4.2 Sans codage des bits<br />
Sans codage la probabilité qu’un bit logique soit faux (p) <strong>et</strong> la même que celle qu’un bit<br />
physiquement transmis le soit :<br />
p= p phy<br />
Équation 30<br />
6.4.3 Avec un codage FEC (Forwar Error Correction) 1/3 1<br />
Probabilité que 3 bits de suite soit correcte :<br />
C<br />
( − p ) 3<br />
= ( − p ) 3<br />
o 0<br />
3 ⋅ pphy⋅1 phy 1 phy<br />
Équation 31<br />
L’ Équation 31 se démontre grâce à la variable aléatoire Binomiale [PAT].<br />
Probabilité que 1 des 3 bits soit faux (ou que 2 soit correcte) :<br />
C<br />
( − p ) 2<br />
= 3⋅<br />
p ⋅( − p ) 2<br />
1 1<br />
3⋅<br />
pphy⋅1 phy phy 1 phy<br />
Équation 32<br />
L’ Équation 32 se démontre grâce à la variable aléatoire Binomiale [PAT].<br />
Probabilité qu’un bit logique soit faux :<br />
p=<br />
3<br />
( 1−<br />
p ) 3 ( 1 ) )<br />
2<br />
phy + ⋅pphy⋅<br />
− p<br />
1−<br />
phy<br />
Équation 33<br />
L’Équation 33 signifie qu’un bit logique est faux si il y a plus d'un bit faux sur les 3.<br />
1 Le codage FEC 1/3 signifie que tous les bits sont transmis 3 fois à l’identique <strong>et</strong> que la décision est<br />
prise à la majorité.<br />
130
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.4.4 Calcule du débit réel connaissant le probabilité de transmission<br />
d’un bit logique (pour FEC 1/3 <strong>et</strong> sans codage)<br />
Probabilité que le paqu<strong>et</strong> soit correctement transmis :<br />
( ) i +<br />
−<br />
e<br />
Ppbt= 1 p<br />
Équation 34<br />
L’Équation 34 se démontre grâce à la variable aléatoire Binomiale ou Géométrique<br />
[PAT].<br />
Probabilité que la quittance soit correctement transmis :<br />
P<br />
qbt<br />
( − p) c<br />
= 1<br />
Équation 35<br />
Même démonstration pour l’Équation 35 que pour l’Équation 34.<br />
Probabilité que l’ém<strong>et</strong>teur <strong>et</strong> le récepteur considère que le paqu<strong>et</strong> est correctement<br />
transmis :<br />
P<br />
i+<br />
e c i+<br />
e+<br />
c<br />
( 1 − p) ( ⋅1<br />
− p) = ( − p) tbt = Pqbt⋅Ppbt=<br />
1<br />
Équation 36<br />
L’Équation 36 est trouvé grâce à l’Équation 35 <strong>et</strong> à l’Équation 34. La paqu<strong>et</strong> <strong>et</strong> la<br />
quittance doivent être exempt d’erreur pour pouvoir transm<strong>et</strong>tre le paqu<strong>et</strong> suivant.<br />
Le temps de transmission d’un paqu<strong>et</strong> <strong>et</strong> de sa quittance :<br />
( i+<br />
e+<br />
c) FEC<br />
T =<br />
1<br />
D<br />
1 ⋅ ⋅<br />
Équation 37<br />
131
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Espérance mathématique jusqu’à la première transmission correctement effectuée 1 :<br />
μ = 1<br />
P tbt<br />
Équation 38<br />
L’Équation 38 se démontre grâce à la variable aléatoire Géométrique [PAT].<br />
Temps d’attente moyen jusqu’à la première transmission correctement effectuée :<br />
( i+<br />
e+<br />
c) FEC<br />
T =μ ⋅T<br />
= 1 ⋅ 1 ⋅<br />
P D<br />
⋅<br />
bt<br />
1<br />
tbt<br />
Équation 39<br />
L’Équation 39 se trouve grâce à l’Équation 38 <strong>et</strong> à l’Équation 37.<br />
Débit théorique de l’information utile :<br />
D<br />
T i<br />
théo =<br />
Équation 40<br />
Débit réel de l’information utile :<br />
D<br />
réel<br />
=<br />
T i =<br />
bt 1<br />
P<br />
tbt<br />
i<br />
⋅ 1 ⋅<br />
D<br />
( i+<br />
e+<br />
c)<br />
Équation 41<br />
⋅FEC=<br />
Ptbt⋅D<br />
théo<br />
L’Équation 41 est trouvé grâce au développement mathématique de l’Équation 40 <strong>et</strong><br />
de l’Équation 39.<br />
1 Nombre de paqu<strong>et</strong> qu’il faut envoyer jusqu’au premier succès<br />
132
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.4.5 Avec un codage FEC 2/3 1 :<br />
Avec ce codage, on a forcément un multiple de 10 bits auquel on rajoute 5 bits de<br />
contrôle qui perm<strong>et</strong>tent de corriger une erreur. La notion de bit logique <strong>et</strong> bit physique<br />
ne peut plus être utilisé. La meilleur solution est de prendre les bits par paqu<strong>et</strong> de 10.<br />
Les formules ci-dessus doivent donc être légèrement modifié.<br />
Probabilité que 10 bits de suite soit correcte :<br />
C<br />
( − p ) 15<br />
= ( − p ) 15<br />
o 0<br />
15⋅<br />
pphy⋅1 phy 1 phy<br />
Équation 42<br />
L’Équation 42 se démontre grâce à la variable aléatoire Binomiale [PAT].<br />
Probabilité que 1 sur 10 bits soit faux (ou que 9 sur 10 soit correct) :<br />
C<br />
( − p ) 14<br />
= 15⋅<br />
p ⋅( − p ) 14<br />
1 1<br />
14⋅<br />
pphy⋅1 phy<br />
phy 1 phy<br />
Équation 43<br />
L’Équation 43 se démontre grâce à la variable aléatoire Binomiale [PAT].<br />
Probabilité qu’un bit logique soit faux :<br />
P<br />
15<br />
( 1−<br />
p ) 15 ( ) )<br />
14<br />
phy + ⋅pphy⋅<br />
− p<br />
Fec23=<br />
1−<br />
1 phy<br />
Équation 44<br />
L’Équation 44 signifie qu’une série de 10 bits est fausse si il y a plus d'un bit faux sur<br />
les 10.<br />
Probabilité que le paqu<strong>et</strong> avec les informations soit correctement transmis :<br />
=<br />
i+<br />
e<br />
( 1−<br />
23) 10<br />
Ppbt PFec<br />
Équation 45<br />
1 Le codage FEC 2/3 génère 15 bits avec 10 bits c’est-à-dire 50% plus de bit<br />
133
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
L’Équation 45 se démontre grâce à la variable aléatoire Binomiale ou Géométrique<br />
[PAT].<br />
Probabilité que la quittance soit correctement transmise :<br />
P<br />
=<br />
c<br />
( 1−<br />
23) 10<br />
qbt PFec<br />
Équation 46<br />
Même démonstration pour l’Équation 46 que pour l’Équation 45.<br />
Probabilité que l’ém<strong>et</strong>teur <strong>et</strong> le récepteur considère que le paqu<strong>et</strong> est correctement<br />
transmis :<br />
P<br />
tbt<br />
= P<br />
qbt<br />
⋅P<br />
pbt<br />
=<br />
i+<br />
e<br />
i+<br />
e+<br />
c<br />
( 1−P<br />
Fec23) 10<br />
( ⋅1<br />
−PFec23) 10<br />
= ( 1−<br />
PFec23) 10<br />
Équation 47<br />
c<br />
L’Équation 47 est trouvé grâce à l’Équation 46 <strong>et</strong> l’Équation 45. La paqu<strong>et</strong> <strong>et</strong> la<br />
quittance doivent être exempt d’erreur pour pouvoir transm<strong>et</strong>tre le paqu<strong>et</strong> suivant.<br />
Le temps de transmission d’un paqu<strong>et</strong> <strong>et</strong> de sa quittance :<br />
( i+<br />
e+<br />
c) FEC<br />
T =<br />
1<br />
D<br />
1 ⋅ ⋅<br />
Équation 48<br />
Espérance mathématique jusqu’à la première transmission correctement effectuée 1 :<br />
μ = 1<br />
P tbt<br />
Équation 49<br />
L’ Équation 49 se démontre grâce à la variable aléatoire Géométrique [PAT].<br />
1 Nombre de paqu<strong>et</strong> qu’il faut envoyer jusqu’au premier succès<br />
134
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Temps d’attente moyen jusqu’à la première transmission correctement effectuée :<br />
( i+<br />
e+<br />
c) FEC<br />
T =μ ⋅T<br />
= 1 ⋅ 1 ⋅<br />
P D<br />
⋅<br />
bt<br />
1<br />
tbt<br />
Équation 50<br />
L’Équation 50 se trouve grâce à l’Équation 49 <strong>et</strong> l’Équation 48.<br />
Débit théorique de l’information utile :<br />
D<br />
T i<br />
théo =<br />
Équation 51<br />
Débit réel de l’information utile :<br />
D<br />
réel<br />
=<br />
T i =<br />
bt 1<br />
P<br />
tbt<br />
i<br />
⋅ 1 ⋅<br />
D<br />
( i+<br />
e+<br />
c)<br />
Équation 52<br />
⋅FEC=<br />
Ptbt⋅D<br />
théo<br />
L’Équation 52 est trouvé grâce au développement mathématique de l’Équation 51 <strong>et</strong><br />
l’Équation 50.<br />
135
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.5 Débit réel des paqu<strong>et</strong>s Blu<strong>et</strong>ooth<br />
Dans ce chapitre, le débit de Blu<strong>et</strong>ooth est calculé d'après un taux d'erreur par bit. Ces<br />
calculs ne serviront pas pour nos mesures, mais aideront à la compréhension de la<br />
problématique des erreurs engendrées sur Blu<strong>et</strong>ooth.<br />
6.5.1 Code d’accès<br />
Le code d'accès est utilisé avec un corrélateur <strong>et</strong> une valeur stockée précédemment.<br />
Une ou même quelques erreur(s) sur le code d'accès n'ont pas d'incidence car le<br />
corrélateur passera quand même le seuil.<br />
6.5.2 Entête<br />
L’entête est protégé, comme expliqué plus haut, par un FEC 1/3 <strong>et</strong> par un HEC qui<br />
très puissant. La méthode pour calculer la probabilité de transm<strong>et</strong>tre l’entête<br />
correctement est inspirer des développements des chapitres 6.4.4.<br />
Probabilité que l’entête 1 soit correctement transmis :<br />
P<br />
BEBT<br />
= (( 1−<br />
p<br />
p<br />
phy)<br />
3 + 3⋅<br />
pphy⋅(1−<br />
)<br />
2<br />
) 18<br />
Équation 53<br />
L’Équation 53 se démontre grâce à l’Équation 33 <strong>et</strong> l’Équation 35.<br />
100%<br />
90%<br />
80%<br />
70%<br />
60%<br />
50%<br />
0% 1% 2% 3% 4% 5% 6% 7% 8% 9%<br />
Taux d'erreur par bit phys ique<br />
Figure 78 : Probabilité de transmission correcte de l’entête Blu<strong>et</strong>ooth connaissant le taux d’erreur<br />
1 Rappelons pour ceux qui n’aurait pas lu tout le document que l’entête en Blu<strong>et</strong>ooth fait 54 bits mais<br />
18 bits logique (à cause du FEC 1/3)<br />
136
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.5.3 Cargaison par type<br />
La norme de Blu<strong>et</strong>ooth offre la possibilité d’utiliser diffèrent type de paqu<strong>et</strong>, comme<br />
expliqué au chapitre 3. Le débit réel influe considérablement <strong>entre</strong> les différents<br />
paqu<strong>et</strong>s. Ceci est dû aux différentes forme de codage <strong>et</strong> la taille des paqu<strong>et</strong>s. La<br />
méthode reste la même que pour " Modèle mathématique général du débit ", c'est-àdire<br />
que le moindre faute sur bit logique est détecter <strong>et</strong> qu'une quittance négative est<br />
envoyée.<br />
6.5.3.1 DH1<br />
Les paqu<strong>et</strong>s du type DH n'ont pas de codage. On voyant la Figure 33, la cargaison de<br />
ce type de paqu<strong>et</strong> possède un entête de 1 byte <strong>et</strong> 2 bytes de CRC. Le nombre de bit<br />
maximum 1 de la cargaison vaut 240 bits (voir Figure 79).<br />
8 bits 216 bits 16 bits<br />
Entête de cargaison Bits d'information CRC<br />
Figure 79 : Représentation de la cargaison en DH1<br />
La probabilité que la cargaison d'un paqu<strong>et</strong> DH soit bien transmis :<br />
=<br />
bitcargaison<br />
( 1− )<br />
PCDH pphy<br />
Équation 54<br />
L'Équation 54 est démontré grâce à l'Équation 30 <strong>et</strong> l'Équation 34. Le nombre de bit<br />
correcte doit être celui de la cargaison.<br />
La probabilité que la cargaison d'un paqu<strong>et</strong> DH1 soit correctement transmis :<br />
P<br />
=<br />
( − p ) 240<br />
CDH1 1 phy<br />
Équation 55<br />
1 Le capacité maximum de chaque type<br />
137
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
L'Équation 55 est démontré grâce à l'Équation 54 pour le cas des paqu<strong>et</strong>s DH1.<br />
La probabilité que le paqu<strong>et</strong> DH1 en entier soit correctement transmis :<br />
P<br />
DH1<br />
= PCDH1⋅<br />
P<br />
Équation 56<br />
BEBT<br />
L'Équation 56 se démontre grâce à l'Équation 55 <strong>et</strong> l'Équation 53. Pour que le paqu<strong>et</strong><br />
soit correct, l'entête <strong>et</strong> la cargaison doivent être correct.<br />
La probabilité que le paqu<strong>et</strong> arrive correctement est la même que le pourcentage de<br />
débit, ceci s'explique avec la variable aléatoire Géométrique.<br />
100%<br />
80%<br />
Débit réel<br />
60%<br />
40%<br />
20%<br />
0%<br />
0.0% 0.5% 1.0% 1.5% 2.0% 2.5% 3.0%<br />
Taux d'erreur par bit physique<br />
Figure 80 : Pourcentage du débit réel des paqu<strong>et</strong>s DH1 en connaissant le taux d'erreur par bit<br />
138
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.5.3.2 DH3<br />
La taille des paqu<strong>et</strong>s DH3 est plus élevé, ils prennent 3 slots de temps. Le nombre de<br />
bit maximum de la cargaison vaut 1496 bits (voir Figure 81)<br />
16 bits 1464 bits 16 bits<br />
Entête de cargaison Bits d'information CRC<br />
Figure 81 : Représentation de la cargaison en DH3<br />
La probabilité que la cargaison d'un paqu<strong>et</strong> DH3 soit correctement transmis :<br />
P<br />
=<br />
( − p ) 1496<br />
CDH3 1 phy<br />
Équation 57<br />
L'Équation 57 est démontré grâce à l'Équation 54 pour le cas des paqu<strong>et</strong>s DH3.<br />
La probabilité que le paqu<strong>et</strong> DH3 en entier soit correctement transmis :<br />
P<br />
DH3<br />
= PCDH3<br />
⋅P<br />
Équation 58<br />
BEBT<br />
L'Équation 58 se démontre grâce à l'Équation 57 <strong>et</strong> l'Équation 53. Pour que le paqu<strong>et</strong><br />
soit correct, l'entête <strong>et</strong> la cargaison doivent être correct.<br />
139
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
100%<br />
90%<br />
80%<br />
70%<br />
Débit réel<br />
60%<br />
50%<br />
40%<br />
30%<br />
20%<br />
10%<br />
0%<br />
0.00% 0.05% 0.10% 0.15% 0.20% 0.25% 0.30%<br />
Taux d'erreur par bit physique<br />
Figure 82 : Pourcentage du débit réel des paqu<strong>et</strong>s DH3 en connaissant le taux d'erreur par bit<br />
6.5.3.3 DH5<br />
La taille des paqu<strong>et</strong>s DH5 est plus élevé, ils prennent 5 slots de temps. Le nombre de<br />
bit maximum de la cargaison vaut 2744 bits (voir Figure 81)<br />
16 bits 2712 bits 16 bits<br />
Entête de cargaison Bits d'information CRC<br />
Figure 83 : Représentation de la cargaison en DH3<br />
La probabilité que la cargaison d'un paqu<strong>et</strong> DH3 soit correctement transmis :<br />
P<br />
=<br />
( − p ) 2744<br />
CDH5 1 phy<br />
Équation 59<br />
L'Équation 59 est démontré grâce à l'Équation 54 pour le cas des paqu<strong>et</strong>s DH3.<br />
140
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
La probabilité que le paqu<strong>et</strong> DH5 en entier soit correctement transmis :<br />
P<br />
DH5<br />
= PCDH5<br />
⋅P<br />
Équation 60<br />
BEBT<br />
L'Équation 60 se démontre grâce à l'Équation 59 <strong>et</strong> l'Équation 53. Pour que le paqu<strong>et</strong><br />
soit correct, l'entête <strong>et</strong> la cargaison doivent être correct.<br />
100%<br />
80%<br />
Débit réel<br />
60%<br />
40%<br />
20%<br />
0%<br />
0.00% 0.05% 0.10% 0.15% 0.20% 0.25% 0.30%<br />
Taux d'erreur par bit physique<br />
Figure 84 : Pourcentage du débit réel des paqu<strong>et</strong>s DH5 en connaissant le taux d'erreur par bit<br />
500000<br />
Débit en bits par seconde<br />
400000<br />
300000<br />
200000<br />
100000<br />
DH1<br />
DH3<br />
DH5<br />
0<br />
0.00% 0.05% 0.10% 0.15% 0.20% 0.25% 0.30% 0.35%<br />
pourcentage d'erreur par bit physique<br />
Figure 85 : Comparaison des débits symétrique <strong>entre</strong> paqu<strong>et</strong> DH avec un taux d'erreur<br />
141
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.5.3.4 DM1<br />
Les paqu<strong>et</strong>s du type DM ont un codage FEC 2/3 expliqué au chapitre 6.4.5. La taille<br />
maximum des paqu<strong>et</strong>s est considérée <strong>et</strong> doit être un multiple de 10.<br />
Probabilité générale de transm<strong>et</strong>tre correctement la cargaison d'un paqu<strong>et</strong> DM avec k<br />
bits logique de cargaison :<br />
P<br />
CDM<br />
=<br />
( ) ( ) ) 14 k<br />
15<br />
1−<br />
p 15 1<br />
10<br />
phy + ⋅pphy⋅<br />
− pphy<br />
Équation 61<br />
L'Équation 61 se démontre en appliquant les formules générales de l'Équation 44 <strong>et</strong> de<br />
l'Équation 45.<br />
La taille de la cargaison d'un paqu<strong>et</strong> DM1 est de 17 bytes d'information, de 1 byte<br />
d'entête <strong>et</strong> de 2 bytes de CRC ce qui fait 160 bits.<br />
Probabilité que la cargaison d'un paqu<strong>et</strong> DM1 soit transmis correctement :<br />
P<br />
15<br />
( 1−<br />
p ) 15 ( ) ) 14 16<br />
phy + ⋅pphy⋅<br />
− pphy<br />
CDM1=<br />
1<br />
Équation 62<br />
L'Équation 62 se démontre grâce à l'Équation 61 pour les paqu<strong>et</strong>s du type DM1.<br />
La probabilité que le paqu<strong>et</strong> en entier soit correctement transmis :<br />
P<br />
DM1<br />
= PCDM1<br />
⋅P<br />
Équation 63<br />
BEBT<br />
L'Équation 63 se démontre grâce à l'Équation 62 <strong>et</strong> l'Équation 53. Pour que le paqu<strong>et</strong><br />
soit correct, l'entête <strong>et</strong> la cargaison doivent être correct.<br />
142
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
100%<br />
80%<br />
Débit réel<br />
60%<br />
40%<br />
20%<br />
0%<br />
0.00% 1.00% 2.00% 3.00% 4.00% 5.00%<br />
Taux d'erreur par bit physique<br />
Figure 86 : Pourcentage du débit réel des paqu<strong>et</strong>s DM1 en connaissant le taux d'erreur par bit<br />
6.5.3.5 DM3<br />
La taille de la cargaison d'un paqu<strong>et</strong> DM3 est de 121 bytes d'information, de 1 byte<br />
d'entête <strong>et</strong> de 2 bytes de CRC ce qui fait 1000 bits.<br />
Probabilité que la cargaison d'un paqu<strong>et</strong> DM3 soit transmis correctement :<br />
P<br />
15<br />
( 1−<br />
p ) 15 ( ) ) 14 100<br />
phy + ⋅pphy⋅<br />
− pphy<br />
CDM3=<br />
1<br />
Équation 64<br />
L'Équation 64 se démontre grâce à l'Équation 61 pour les paqu<strong>et</strong>s du type DM3.<br />
La probabilité que le paqu<strong>et</strong> en entier soit correctement transmis :<br />
P<br />
DM3<br />
= PCDM3<br />
⋅P<br />
Équation 65<br />
BEBT<br />
L'Équation 65 se démontre grâce à l'Équation 64 <strong>et</strong> l'Équation 53. Pour que le paqu<strong>et</strong><br />
soit correct, l'entête <strong>et</strong> la cargaison doivent être correct.<br />
143
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
100%<br />
80%<br />
Débit réel<br />
60%<br />
40%<br />
20%<br />
0%<br />
0.00% 0.50% 1.00% 1.50% 2.00% 2.50% 3.00%<br />
Taux d'erreur par bit physique<br />
Figure 87 : Pourcentage du débit réel des paqu<strong>et</strong>s DM3 en connaissant le taux d'erreur par bit<br />
6.5.3.6 DM5<br />
La taille de la cargaison d'un paqu<strong>et</strong> DM5 est de 224 bytes d'information, de 1 byte<br />
d'entête <strong>et</strong> de 2 bytes de CRC ce qui fait 1824 bits. A cause du codage FEC 2/3, 1830<br />
bits seront utilisés.<br />
Probabilité que la cargaison d'un paqu<strong>et</strong> DM5 soit transmis correctement :<br />
P<br />
15<br />
( 1−<br />
p ) 15 ( ) ) 14 183<br />
phy + ⋅pphy⋅<br />
− pphy<br />
CDM5=<br />
1<br />
Équation 66<br />
L'Équation 66 se démontre grâce à l'Équation 61 pour les paqu<strong>et</strong>s du type DM5.<br />
La probabilité que le paqu<strong>et</strong> en entier soit correctement transmis :<br />
P<br />
DM5<br />
= PCDM5<br />
⋅P<br />
Équation 67<br />
BEBT<br />
L'Équation 67 se démontre grâce à l'Équation 66 <strong>et</strong> l'Équation 53. Pour que le paqu<strong>et</strong><br />
soit correct, l'entête <strong>et</strong> la cargaison doivent être correct.<br />
144
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
100%<br />
80%<br />
Débit réel<br />
60%<br />
40%<br />
20%<br />
0%<br />
0.00% 0.50% 1.00% 1.50% 2.00%<br />
Taux d'erreur par bit physique<br />
Figure 88 : Pourcentage du débit réel des paqu<strong>et</strong>s DM5 en connaissant le taux d'erreur par bit<br />
145
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.5.4 Simulation en JAVA<br />
Pour contrôler l'exactitude des calculs du chapitre 6.5, Un modèle de transmission<br />
pour les paqu<strong>et</strong>s DH1 a été simulé. Les courbes pourront être comparer pour vérifier<br />
nos calculs.<br />
Sans <strong>entre</strong>r dans les détails, le programme, écrit en JAVA, fonctionne en utilisant la<br />
classe Random 1 pour simuler le taux d'erreur. Le codage FEC 1/3 est simplement<br />
codé avec 3 bit à la majorité. Pour plus de détails sur le programme, le listing se trouve<br />
en Annexe de ce document.<br />
100%<br />
80%<br />
Débit réel<br />
60%<br />
40%<br />
Simulation<br />
Théorie<br />
20%<br />
0%<br />
0.0% 0.5% 1.0% 1.5%<br />
Taux d'erreur par bit physique<br />
Figure 89 : Comparaison <strong>entre</strong> la simulation <strong>et</strong> la théorie pour les paqu<strong>et</strong>s DH1<br />
Pour les paqu<strong>et</strong>s de type DM1, la méthode est de codé en FEC 2/3 d'appliquer le taux<br />
d'erreur puis enfin de décoder.<br />
1 aléatoire<br />
146
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
100%<br />
80%<br />
Débit réel<br />
60%<br />
40%<br />
Simulation<br />
Théorie<br />
20%<br />
0%<br />
0% 2% 4% 6%<br />
Taux d'erreur par bit physique<br />
Figure 90 : Comparaison <strong>entre</strong> la simulation <strong>et</strong> la théorie pour les paqu<strong>et</strong>s DM1<br />
Les courbes se superpose parfaitement. La courbe simuler n'est parfaitement lissée<br />
mais le devient si on augmente le temps de simulation (augmente le nombre de paqu<strong>et</strong><br />
à transm<strong>et</strong>tre). Les calculs pour le débit paraissent donc correcte.<br />
6.5.5 Conclusion débit Blu<strong>et</strong>ooth<br />
La robustesse du codage FEC 1/3, <strong>et</strong> dans une moindre mesure FEC 2/3, a fait ses<br />
preuves d'après les calculs ci-dessus. Le débit Blu<strong>et</strong>ooth s'effondre assez rapidement<br />
pour les paqu<strong>et</strong>s sans protection (type DH). Le choix du type de paqu<strong>et</strong> est donc<br />
primordial, il se fait en connaissant l'environnement de travail. La principal<br />
caractéristique de robustesse de Blu<strong>et</strong>ooth reste les sauts de fréquence.<br />
147
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.6 Débit théorique de <strong>WLAN</strong><br />
Le modèle général ne s'applique pas vraiment avec <strong>WLAN</strong>. Le taux d'erreur d'une<br />
partie du paqu<strong>et</strong> n'est pas la même celui du reste. C<strong>et</strong>te différence est due à la vitesse<br />
de transmission qui diffère. Les calculs ci-dessous correspondent à la norme <strong>802.11</strong>b.<br />
Comme d'habitude dans nos développements théoriques, les hypothèses suivantes<br />
sont faites :<br />
• Les contrôleurs détectent toutes les erreurs sans possibilité d'avoir une<br />
fausse acceptation.<br />
• Les erreurs sur des bits voisins ne modifient pas la probabilité d'erreur<br />
de ce bit.<br />
Deux probabilités d'erreurs sur des bits physiques existent :<br />
• P 1 = probabilité de transm<strong>et</strong>tre un bit à 1MHz.<br />
• P 11 = probabilité de transm<strong>et</strong>tre un bit à 11MHz.<br />
6.6.1 Préambule PLCP<br />
Le PLCP préambule est décomposés en deux parties comme le montre la Figure 91.<br />
Figure 91 : Représentation du préambule PLCP<br />
Les premiers 128 bits sont utilisés pour la synchronisation de bit. La séquence est une<br />
alternance de 1 <strong>et</strong> de 0. Ces premiers bits peuvent être considérés comme<br />
correctement transmis même en cas de multiple erreurs.<br />
Le SFD est séquence de 16 bits pour le synchronisation de trame.<br />
148
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.6.2 Entête PLCP<br />
L'entête PLCP est de taille fixe. Il est aussi protégé par un HEC de 16 bits qui perm<strong>et</strong><br />
de détecter toutes les erreurs. La taille complète de l'entête est de 48 bits. Probabilité<br />
que l'entête soit correctement transmis :<br />
Pent<strong>et</strong>e<br />
= ( 1−<br />
p1)<br />
Équation 68<br />
L'Équation 68 est déduite de l'Équation 34.<br />
48<br />
6.6.3 Payload de PLCP<br />
Le payload de la couche PLCP est le PDU-MAC (trame MAC). C<strong>et</strong>te trame est<br />
protégé par CRC de 32 bits. Pour qu'elle soit correctement arrivée, la transmission doit<br />
être exempt erreur. Comme le montre le chapitre 2, la taille de la cargaison MAC peut<br />
varier <strong>entre</strong> 1-2312 bytes qui a comme abréviation C. La taille des trames MAC général<br />
(pas celle de contrôle) peut être comprise <strong>entre</strong> 35-2346 (entête + cargaison + CRC).<br />
Probabilité de transm<strong>et</strong>tre correctement une trame MAC :<br />
P<br />
MAC<br />
= (1−<br />
p<br />
(34+<br />
C)<br />
⋅8<br />
11)<br />
Équation 69<br />
L'Équation 69 se démontre comme l'Équation 68.<br />
Figure 92 : débit réel de la couche MAC<br />
149
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
6.6.4 Débit réel de <strong>WLAN</strong><br />
Le débit maximum de bit est de 11Mbit/s. Le débit réel efficace est de beaucoup<br />
moins, les raisons sont les suivantes :<br />
• Une partie de la transmission est faite à 1 Mbit/s<br />
• Une partie des bits transmis servent au contrôle de la transmission.<br />
Probabilité de transm<strong>et</strong>tre correctement un paqu<strong>et</strong> au niveau de la couche PLCP :<br />
P<br />
PLCP<br />
= P<br />
Équation 70<br />
L'Équation 70 est la multiplication <strong>entre</strong> l'Équation 68 <strong>et</strong> l'Équation 69.<br />
MAC<br />
⋅P<br />
ent<strong>et</strong>e<br />
6.6.5 Influence de la taille des paqu<strong>et</strong>s<br />
La taille des paqu<strong>et</strong>s <strong>WLAN</strong> influe considérablement le débit réel en cas de fort taux<br />
d'erreur (voir Figure 92). Plus un paqu<strong>et</strong> est grand, plus la probabilité qu'au moins un<br />
bit soit faux augmente (voir Équation 68). En contre partie, chaque paqu<strong>et</strong> transporte<br />
une quantité de bit sans information (utile pour le protocole). Plus un paqu<strong>et</strong> est de<br />
taille importante moins ses bits sans information diminuent le débit utile. La mission<br />
est de trouver le choix le plus approprié d'après le taux d'erreur. La Figure 93 montre<br />
d'après le taux d'erreur qu'elle est la taille qui optimise la transmission. La dimension<br />
est un paramètre important en ce qui concerne les performances de <strong>WLAN</strong> (voir<br />
chapitre 4).<br />
150
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Figure 93 : Représentation du débit utile d'après le taux d'erreur en <strong>WLAN</strong> avec une<br />
transmission à 11 Mbit/s<br />
151
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
152
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
7 Mesures<br />
153
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
7.1 Conditions de mesures<br />
7.1.1 Environnement<br />
Afin de pouvoir comparer les résultats de la mesure avec ceux obtenus de manière<br />
théorique, il s’agit de reproduire au mieux les conditions appliquées lors des<br />
simulations. Deux problèmes principaux se posent pour reproduire les conditions de<br />
simulation dans la réalité d’une mesure. Le premier problème est que dans un<br />
laboratoire, les ondes subissent de nombreuses réflexions, ce qui peut engendrer une<br />
forte dégradation du signal (voir chapitre 6 : Modèles théoriques). Un deuxième<br />
problème est qu’il est impossible de réaliser des mesures avec des dispositifs situés à<br />
des dizaines de mètre les un des autres. Afin de recréer les conditions spatiales du<br />
modèle théorique, il existe deux possibilités ; faire les mesures en plein air ou dans une<br />
chambre anéchoïque.<br />
Figure 94 : Chambre anéchoïque (source : Acoustic Group)<br />
La mesure en chambre anéchoïque est idéale sur le plan des réflexions. En eff<strong>et</strong>, dans<br />
une chambre anéchoïque les parois ont une géométrie particulière perm<strong>et</strong>tant<br />
d’atténuer fortement les réflexions, ce qui perm<strong>et</strong> d’obtenir les conditions rencontrées<br />
dans un endroit totalement dégagé. L’inconvénient de la chambre anéchoïque est<br />
qu’elle n’est pas assez grande pour perm<strong>et</strong>tre d’étudier des réseaux étendus. Il n’est pas<br />
possible de séparer les dispositifs à plusieurs dizaines de mètres. Cependant, en<br />
154
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
effectuant des mesures à des distances réduites, il est ensuite possible par calcul d’en<br />
tirer des résultats pour des distances plus importantes.<br />
La possibilité de travailler en plein air, sur un terrain dégagé, perm<strong>et</strong> de recréer les<br />
conditions de simulation exactes au niveau des distances. Cependant, les réflexions ne<br />
sont pas entièrement écartées, car une partie des ondes sera réfléchie par le sol.<br />
Figure 95 : Ondes réfléchies par le sol<br />
Les ondes réfléchies par le sol peuvent être à l’origine d’interférences. Afin de limiter<br />
l’eff<strong>et</strong> des réflexion, les dispositifs ne seront pas posés à même le sol, mais surélevé<br />
(comme c’est généralement le cas dans la réalité).<br />
Comme expliqué dans le modèle de propagation des ondes, les conditions<br />
météorologiques au moment de la mesure ont une influence minime sur les résultats<br />
de mesure. Elles ne sont pas relevées.<br />
155
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
7.1.2 Equipement<br />
L’équipement nécessaire pour les mesures est assez sommaire. Deux ordinateurs<br />
portables, dont un équipé d’un analyseur de protocole <strong>802.11</strong> (AiroPeek), servent à<br />
générer du trafic <strong>802.11</strong>b. L’analyseur perm<strong>et</strong> de récolter des informations sur les<br />
trames reçues par le récepteur <strong>WLAN</strong>. Le portable utilisé comme récepteur comporte<br />
deux cartes réseaux <strong>WLAN</strong>, une pour la réception <strong>et</strong> une pour l’analyseur. C<strong>et</strong>te<br />
configuration perm<strong>et</strong> de limiter le nombre de portables utilisés pour la mesure, mais<br />
ne perturbe pas la communication car la carte utilisée par l’analyseur ne fait que<br />
recevoir de l’information.<br />
Figure 96 : Schéma de mesure<br />
Deux autres portables sont nécessaires pour générer du trafic Blu<strong>et</strong>ooth. La<br />
communication consiste en un transfert de fichier à l’aide du logiciel Bluel<strong>et</strong>. La<br />
puissance des dispositifs Blu<strong>et</strong>ooth est de 1 mW, ce qui correspond à la classe de<br />
puissance n°2.<br />
156
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
7.2 Mesures<br />
7.2.1 Mesures en plein air<br />
C<strong>et</strong>te mesure a été réalisée sur un terrain de football, il s’agissait donc d’un endroit<br />
dégagé, où du moins un endroit assez dégagé pour que l’eff<strong>et</strong> des réflexions (autres<br />
que celles du sol) puissent être négligées. Deux séries de mesures ont été effectuées,<br />
l’une avec le logiciel de génération de trafic <strong>802.11</strong>b PRISM Benchmark Pro, <strong>et</strong> l’autre<br />
au moyen de LAN Evaluation (voir chapitre sur la documentation logicielle).<br />
Figure 97 : Résultats de la mesure en plein air<br />
7.2.2 Mesures en chambre anéchoïque<br />
7.2.2.1 Conditions de mesures<br />
Les mesures en chambre anéchoïque ont été réalisées à Berne dans les laboratoires de<br />
METAS. Le sol n’étant pas recouvert d’une structure absorbante, les réflexions contre<br />
le sol n’ont pu être évitées.<br />
Bien que les dimensions de la salle ne perm<strong>et</strong>tent pas de reproduire les distances<br />
utilisées lors de la simulation, cela a en réalité peu d’importance. En eff<strong>et</strong> le paramètre<br />
important pour les perturbations est le rapport signal sur interférence S/I. Le rapport<br />
S/I est, dans le cadre de c<strong>et</strong>te mesure, directement proportionnel au rapport <strong>entre</strong> les<br />
157
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
distances <strong>entre</strong> dispositif <strong>WLAN</strong> <strong>et</strong> Blu<strong>et</strong>ooth, car la puissance des ém<strong>et</strong>teurs n’est pas<br />
modifiée pendant la mesure <strong>et</strong> peut être considérée comme constante (en réalité il<br />
existe de p<strong>et</strong>ites différentes en fonctions des fréquences utilisées).<br />
Figure 98 : Chambre anéchoïque de METAS<br />
7.2.2.2 Mesure du spectre de Blu<strong>et</strong>ooth<br />
Afin de mieux comprendre les interférences <strong>entre</strong> Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong>, une mesure<br />
du spectre de Blu<strong>et</strong>ooth a été menée avec l’aide de Heinrich Ryser. C<strong>et</strong>te mesure doit<br />
perm<strong>et</strong>tre d’obtenir le spectre de Blu<strong>et</strong>ooth jusque pour des puissances très faibles,<br />
afin de m<strong>et</strong>tre en évidence les émissions parasites de Blu<strong>et</strong>ooth.<br />
Les instruments de mesure à disposition, bien que de très haute qualité, sont mal<br />
adaptés à la mesure de signaux transmis avec FHSS. Il n’a pas été possible d’obtenir le<br />
spectre d’un signal Blu<strong>et</strong>ooth pour un canal pendant la durée d’un slot. Car l’analyseur<br />
de spectre opère un balayage en fréquence à une cadence trop faible pour capter<br />
l’ensemble d’une transmission sur un slot. Le problème est que la durée d’un slot est<br />
trop faible pour qu’elle soit à coup sûr balayée. Etant donné que la largeur de bande<br />
maximum sans balayage est de 1 MHz, le balayage est nécessaire car le spectre<br />
Blu<strong>et</strong>ooth avec les émissions parasites est supérieur à 1 MHz.<br />
158
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
La solution est d’utiliser les fonctions max hold <strong>et</strong> peak d<strong>et</strong>ection de l’analyseur, ce qui<br />
perm<strong>et</strong> de conserver la valeur maximum mesurée pour chaque fréquence. Les résultats<br />
de la mesure est présenté à la Figure 99.<br />
Figure 99 : Résultats de mesure du spectre de Blu<strong>et</strong>ooth<br />
Les résultats ne doivent pas être interprétés comme le spectre en un instant donné,<br />
mais comme les valeurs maximums enregistrées durant un intervalle de temps<br />
(quelques dizaines de secondes). La puissance du bruit est donc surévaluée (environ 10<br />
dBm) par rapport à ce qu’elle est réellement, car seules les valeurs maximum ont été<br />
conservées.<br />
Les puissances indiquées sur le graphique ne prennent pas en compte les pertes dues<br />
au facteur d’antenne (AF, 32.3 dB/m) <strong>et</strong> au câble reliant l’antenne à l’analyseur (5dB).<br />
La puissance réelle du signal est donc égale à :<br />
P<br />
+ 32.3<br />
[ dBm]<br />
= Pmesure[<br />
dBm]<br />
+ AF[<br />
dB/<br />
m]<br />
+ Lcable[<br />
dB]<br />
= Pmesure[<br />
dBm]<br />
+<br />
5<br />
159
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
7.2.2.3 Mesure des performances de <strong>WLAN</strong><br />
L’ensemble des mesures a été réalisé à l’aide du générateur de trafic <strong>WLAN</strong> PRISM<br />
BenchMark Pro.<br />
Figure 100 : Comparaison <strong>entre</strong> les résultats de la simulation <strong>et</strong> de la mesure<br />
Le détail des résultats de mesure est annexé en fin de rapport (Annexe 6). La Figure<br />
100 est une comparaison <strong>entre</strong> les résultats de la simulation <strong>et</strong> les résultats de mesure.<br />
Les points de la courbe de mesure ont été calculés en se basant sur le principe de la<br />
majorité :<br />
Pour chaque valeur de S/I, plusieurs mesures ont été réalisées(5 à 10). Dans chacune<br />
des séries de mesures, les valeurs sont très différentes (± 100%) alors que les<br />
conditions de mesure sont restée identiques (du moins en théorie). Cependant, dans<br />
chaque série de mesures, plusieurs résultats sont semblables. Lorsque les résultats<br />
semblables sont majoritaires au sein d’une série de mesure, ils sont considérés comme<br />
bon. Le résultats final est obtenu en faisant la moyenne des bons résultats. Les<br />
résultats du graphiques représentent donc une tendance plutôt qu’une courbe exacte.<br />
160
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
7.3 Analyse des résultats de mesure<br />
7.3.1 Qualité de la mesure<br />
Les mesures portant sur la propagation des ondes électromagnétiques sont délicates à<br />
réalisés. Il faut se montrer très prudent avec les résultats obtenus. Il suffit qu’une<br />
personne se trouve dans la chambre anéchoïque pour que le moindre de ces<br />
mouvements influence de manière significative les résultats. Mais cela n’est pas le seul<br />
facteur d’imprécisions ; la présence d’un ordinateur portable à proximité des<br />
dispositifs peut être une source d’interférence. Pas en tant que source direct de bruit,<br />
mais en tant qu’obstacle à la bonne propagation des ondes. Il est fort probable que la<br />
présence des portables engendrent des réflexions, mais cela est difficile à quantifier.<br />
La seconde hypothèse perm<strong>et</strong>tant d’expliquer les imprécisions de la mesure ne<br />
concerne pas les ondes électromagnétiques, mais le fonctionnement de l’équipement.<br />
Comment être sûr que le fonctionnement du générateur de trafic ou les cartes réseaux<br />
<strong>WLAN</strong> ne sont pas source d’erreurs (problème de buffer, antenne). Cependant c<strong>et</strong>te<br />
hypothèse paraît peu probable <strong>et</strong> elle est difficile à vérifier.<br />
7.3.2 Imprécisions au niveau PLCP<br />
Airopeek fournit le pourcentage de paqu<strong>et</strong> dont le CRC n'est pas correcte.<br />
Malheureusement, il ne perm<strong>et</strong> pas de visionner les erreurs PLCP car il n'a pas accès<br />
aux ressources nécessaire. C'est-à-dire que le taux d'erreur par paqu<strong>et</strong> trouvé avec nos<br />
mesures ne correspond pas exactement avec la réalité. Un paqu<strong>et</strong> erroné à une certaine<br />
probabilité que la transmission Blu<strong>et</strong>ooth fautive commence sur le PLCP <strong>et</strong> donc qu'il<br />
ne soit pas détecté. Pour connaître la probabilité que ceci arrive, il faut connaître la<br />
durée d'une trame MAC <strong>et</strong> de PLCP (préambule <strong>et</strong> entête). Cependant, deux autres<br />
phénomènes <strong>entre</strong> en ligne de compte :<br />
• La modulation <strong>entre</strong> la trame MAC <strong>et</strong> la partie PLCP n'est pas la même,<br />
ce qui rend le PLCP plus robuste que la trame MAC. En cas d'erreur<br />
Blu<strong>et</strong>ooth, le PLCP sera erroné malgré sa résistance. Ce phénomène ne<br />
change donc rien dans ce cas de figure.<br />
161
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
• L'entête de PLCP arrive à faire la synchronisation de bit malgré quelques<br />
erreurs. Pour tenir compte de c<strong>et</strong>te hypothèse, uniquement la moitié de<br />
la durée du préambule sera considérée comme non détectable.<br />
Temps pendant lequel une interférence Blu<strong>et</strong>ooth n'est pas détecté :<br />
T ND=<br />
TEPLCP+<br />
T<br />
Équation 71<br />
NPLCP<br />
2<br />
T EPLCP = durée de l'entête PLCP.<br />
T NPLCP = durée préambule PLCP.<br />
Probabilité qu'un paqu<strong>et</strong> erroné ne soit pas détecté par Airopeek :<br />
P<br />
PA<br />
=<br />
T<br />
MAC<br />
T ND<br />
+ T<br />
Équation 72<br />
PLCP<br />
T MAC = durée trame MAC.<br />
T PLCP =durée PLCP (préambule <strong>et</strong> entête).<br />
Pourcentage réel d'erreur par paqu<strong>et</strong> (avec les erreurs PLCP) :<br />
P<br />
REEL<br />
= P<br />
AIROPEEK<br />
Équation 73<br />
⋅ 1<br />
(1−<br />
P<br />
PA<br />
)<br />
P AIROPEEK = Probabilité de paqu<strong>et</strong> erroné par Airopeek.<br />
1 – P PA = Pourcentage des paqu<strong>et</strong>s faux détectés par Airopeek.<br />
162
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Pour donner un ordre d'idée, le pourcentage d'erreur non détecté par Airopeek avec<br />
des trames MAC qui ont un 1500 bytes d’information :<br />
120<br />
106<br />
P =<br />
= 9.18%<br />
8 ⋅(1500+<br />
34)<br />
+ 192<br />
1110 ⋅<br />
6<br />
106<br />
7.4 Remarques concernant les techniques de mesures<br />
Hormis la chambre anéchoïque, l’équipement utilisé pour ces mesures est relativement<br />
rudimentaire. Les mesures effectuées dans le cadre de c<strong>et</strong>te étude ont valeur<br />
d’approximations. Cependant, un équipement mieux adapté perm<strong>et</strong>trait d’améliorer la<br />
qualité des mesures destinées à l’analyse de la coexistence <strong>entre</strong> <strong>WLAN</strong> <strong>et</strong> Blu<strong>et</strong>ooth :<br />
• Un générateur de trafic Blu<strong>et</strong>ooth est indispensable dans la mesure où il<br />
s’agit de varier le type <strong>et</strong> la dimension des paqu<strong>et</strong>s Blu<strong>et</strong>ooth. Les dispositifs<br />
utilisé lors de c<strong>et</strong>te étude ne fonctionnait qu’avec un seul type d’application<br />
(transfert de fichier avec TCP).<br />
• Lors de c<strong>et</strong>te mesure, il n’a pas été possible de déterminer le comportement<br />
(au niveau fréquentiel <strong>et</strong> au niveau protocole) de Blu<strong>et</strong>ooth. En l’absence de<br />
documentation, le type de paqu<strong>et</strong> <strong>et</strong> de liaison utilisés par un dispositif ou<br />
une application Blu<strong>et</strong>ooth ne peuvent être déterminées autrement que par un<br />
analyseur de protocole.<br />
• Un analyseur au niveau PLCP perm<strong>et</strong>trait d’être informé sur les erreurs au<br />
niveau de la couche PLCP qui ne sont pas détectée par la couche MAC.<br />
• Les problèmes posés par la présence de personne physique dans la chambre<br />
anéchoïque peuvent être écartés en parvenant à configurer <strong>et</strong> lancer des<br />
mesures depuis l’extérieure. C<strong>et</strong>te technique est déjà pratiquée chez METAS,<br />
mais elle demande un investissement important en temps <strong>et</strong> en argent.<br />
Dans toutes les mesures effectuées dans c<strong>et</strong>te étude, les réflexions contre le sol était<br />
présentes. Pour les éliminer, il s’agit de disposer d’une chambre entièrement tapissé<br />
de parois absorbantes.<br />
163
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
8 Analyses <strong>et</strong><br />
solutions<br />
164
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
8.1 <strong>Coexistence</strong> <strong>entre</strong> <strong>802.11</strong>b <strong>et</strong> Blu<strong>et</strong>ooth<br />
8.1.1 Constats<br />
Les baisses de performances de <strong>WLAN</strong> causées par Blu<strong>et</strong>ooth dépendent des<br />
paramètres suivants :<br />
• Rapport signal sur interférence (S/I), directement lié aux puissances<br />
d’émission des dispositifs <strong>et</strong> de leur distance par rapport au récepteur<br />
<strong>WLAN</strong>. Un rapport S/I supérieur à 5 dB perm<strong>et</strong> de garantir que les<br />
communications <strong>WLAN</strong> ne seront pas perturbées par Blu<strong>et</strong>ooth.<br />
• Utilisation de Blu<strong>et</strong>ooth, le type de liaison <strong>et</strong> de paqu<strong>et</strong> utilisés ont une<br />
influence sur les performances de <strong>WLAN</strong>.<br />
• Utilisation de <strong>WLAN</strong>, la dimension des trames, la technique de modulation<br />
<strong>et</strong> le type de protocole utilisé par les couches supérieures (TCP, UDP, …)<br />
font que toutes les applications ne souffrent pas de la même manière de la<br />
présence Blu<strong>et</strong>ooth.<br />
8.1.2 Etat des trames erronées <strong>et</strong> méthodes d’accès au canal<br />
La modulation FHSS utilisée par Blu<strong>et</strong>ooth engendre des paqu<strong>et</strong>s d’erreurs dans les<br />
trames émises par les dispositifs <strong>WLAN</strong>. La majorité des trames erronées par<br />
Blu<strong>et</strong>ooth contient plus de 100 bits erronés. En moyenne il y a <strong>entre</strong> 1000 <strong>et</strong> 2000 bits<br />
erronés par trames erronées. Dans ces conditions, l’utilisation d’un code correcteur<br />
d’erreur est inefficace. Il n’y pas d’autres solutions que de répéter les trames erronées.<br />
Bien qu’elle n’aient pas été conçues pour la coexistence avec Blu<strong>et</strong>ooth, les méthodes<br />
d’accès au canal définie par la norme <strong>802.11</strong> ne sont donc pas à rem<strong>et</strong>tre en cause.<br />
Une solution au problème de la coexistence serait d’avoir une méthode d’accès au<br />
canal tenant compte de Blu<strong>et</strong>ooth. Cependant, c<strong>et</strong>te solution est compliquée à réaliser<br />
<strong>et</strong> des baisses de performances, même réduites, seront toujours à déplorer.<br />
165
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
8.1.3 Dimensionnement des trames<br />
Les simulations, ainsi que les prévisions du chapitre sur la coexistence, démontrent<br />
que la dimension des trames a une influence sur les performances de <strong>WLAN</strong>. La<br />
dimension des trames indiquée sur le graphique de la Figure 101 représente la quantité<br />
d’information avant encapsulation dans une trame MAC.<br />
Figure 101 : Débit en fonction de la dimension des trames<br />
La Figure 101 est une comparaisons des prévisions du chapitre sur la coexistence <strong>et</strong><br />
des résultats obtenu lors des simulations sur Matlab. La simulation a été configurée de<br />
manière à ce que les émissions parasites du dispositif Blu<strong>et</strong>ooth (voir section 8.1.6)<br />
n’aient pas d’influence. Le rapport S/I a donc été choisi à environ –13 dB, ce qui<br />
signifie deux dispositifs <strong>WLAN</strong> à 5 mètres l'un de l'autre <strong>et</strong> un ém<strong>et</strong>teur Blu<strong>et</strong>ooth à<br />
20 cm du récepteur <strong>WLAN</strong>.<br />
166
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Pour les communications à 11 Mbps, plus les trames sont grandes plus le débit sera<br />
important, avec où sans Blu<strong>et</strong>ooth. Alors que pour les communications à 1 Mbps,<br />
utiliser la dimension de trame maximum conduit à un débit très faible (inférieur à 10%<br />
du débit réel sans Blu<strong>et</strong>ooth). Le meilleur débit possible est de 0,44 Mbps, pour cela il<br />
faut des trames contenant 500 à 1200 bytes environ.<br />
8.1.4 Robustesse des techniques de modulation<br />
Le graphique de la Figure 101 montre aussi la robustesse des techniques de<br />
modulation. Comme expliquer dans le chapitre sur la coexistence, les prévisions sont<br />
basées sur la probabilité d’interférence. Elles ne prennent donc pas en compte les<br />
interférences n’engendrant pas d’erreurs grâce aux techniques de modulation à spectre<br />
étalé. Ainsi, les résultats obtenus lors de la simulation donnent des débit au-dessus de<br />
ceux trouver par le modèle statistique utilisé pour les prévisions.<br />
Pour les communications à 11 Mbps, la modulation améliore le débit d’environ 0,5<br />
Mbps. En comparaison avec les résultats obtenus avec la probabilité d’interférence,<br />
cela donne une augmentation du débit <strong>entre</strong> 10 <strong>et</strong> 20%. En ce qui concerne les<br />
communication à 1 Mbps avec plus de 500 bytes d’information dans les trames, la<br />
modulation perm<strong>et</strong> d’obtenir un débit deux fois meilleurs que les prévisions.<br />
La modulation DBPSK, étalée en fréquence avec le code de Barker, utilisée pour les<br />
communications à 1 Mbps est plus robuste que la modulation DQPSK, étalée avec<br />
CCK, utilisée pour les communication à 11 Mbps. Ce constat n’est pas surprenant <strong>et</strong><br />
explique pourquoi le préambule <strong>et</strong> l’entête d’une trame PLCP (transmis à 1 Mbps) ont<br />
un taux d’erreur moins élevé que le corps de la trame (vérifié lors des simulations).<br />
Bien que la modulation utilisée pour les communications à 11 Mbps soit la moins<br />
robuste face aux perturbations causées par Blu<strong>et</strong>ooth, elle perm<strong>et</strong>, quelles que soient<br />
les conditions d’utilisation, d’obtenir les meilleurs débits réels. Changer le débit de<br />
<strong>WLAN</strong> n’est pas une solution au problème de la coexistence.<br />
8.1.5 Utilisation de Blu<strong>et</strong>ooth<br />
8.1.5.1 Type de dispositif<br />
Blu<strong>et</strong>ooth est présent dans de nombreuses <strong>et</strong> diverses applications, chacune de ces<br />
applications ne se comporte pas exactement de la même manière en ce qui concerne<br />
l’occupation de la bande ISM. Par conséquent les performances de <strong>WLAN</strong> dépendent<br />
167
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
aussi du type d’applications utilisées <strong>et</strong> de leur nombre dans l’environnement proche.<br />
Par exemple un téléphone portable équipé de Blu<strong>et</strong>ooth n’est pas nécessairement<br />
constamment en train d’ém<strong>et</strong>tre, ce qui ne serait pas le cas d’un utilisateur qui<br />
utiliserait un casque Blu<strong>et</strong>ooth pour écouter de la musique. Dans c<strong>et</strong>te exemple, le<br />
téléphone portable serait relativement inoffensif pour <strong>WLAN</strong>, alors que la personne<br />
écoutant de la musique serait la cause d’une importante baisse de débit non-seulement<br />
pour son poste de travail connecté par <strong>WLAN</strong>, mais aussi pour quelques stations se<br />
trouvant à proximité (moins de trois mètres).<br />
Il n’est pas indispensable de bannir tout dispositif Blu<strong>et</strong>ooth d’une salle disposant d'un<br />
réseau <strong>WLAN</strong>, mais il s’agit plutôt d’éviter d’équipé des stations avec les deux types de<br />
technologies.<br />
8.1.5.2 Quantité de dispositif<br />
La densité d’ém<strong>et</strong>teurs Blu<strong>et</strong>ooth à proximité d’un récepteur <strong>WLAN</strong> joue un rôle<br />
important. Il faut distinguer deux types de comportement des dispositifs Blu<strong>et</strong>ooth ;<br />
les dispositifs appartenant à un même picon<strong>et</strong> <strong>et</strong> les dispositifs appartenant à des<br />
picon<strong>et</strong>s différents. Les résultats de simulation présentés à la Figure 102 montre la<br />
différence <strong>entre</strong> les perturbations engendrées par un dispositif <strong>et</strong> celles engendrées par<br />
deux dispositifs synchrones (appartenant au même picon<strong>et</strong>).<br />
Figure 102 : Pourcentage de trames erronées avec plusieurs dispositifs Blu<strong>et</strong>ooth<br />
168
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Lorsque des dispositifs Blu<strong>et</strong>ooth communiquent au sein du même picon<strong>et</strong>, ils<br />
communiquent tous selon la même séquence de hop. Le fait qu’il y ait deux, trois où<br />
sept dispositifs ne modifie pas le nombre de changements de fréquences. Le<br />
pourcentage de trames erronées suit donc les résultats obtenu lors des simulations<br />
pour deux dispositifs.<br />
Lorsque les dispositifs appartiennent à des picon<strong>et</strong>s différents, il ém<strong>et</strong>tent chacun sur<br />
des séquences de hop différentes. Dans ce cas, le probabilité qu’une trame soit<br />
erronées est donnée par la formule suivante:<br />
pNBT<br />
((1−<br />
p1) ⋅(1−<br />
)... ⋅ )<br />
= p<br />
1−<br />
2<br />
Équation 74<br />
En adm<strong>et</strong>tant que les dispositifs Blu<strong>et</strong>ooth sont tous à la même distance du récepteur<br />
<strong>WLAN</strong> :<br />
p NBT = 1−(1−<br />
p)<br />
N<br />
Équation 75<br />
p NBT : Pourcentage de trames erronées avec N dispositifs Blu<strong>et</strong>ooth<br />
p : Pourcentage de trames erronées avec un dispositif Blu<strong>et</strong>ooth<br />
N : Nombre de dispositifs Blu<strong>et</strong>ooth<br />
Le nombre de trames erronées augmente donc rapidement en fonction du nombre de<br />
dispositifs environnent.<br />
Il faut cependant préciser qu’à l’heure l’actuelle qu’il est encore rare de voir plusieurs<br />
dispositifs Blu<strong>et</strong>ooth à moins de quelques mètres d’une station. Cela ne veut pas dire<br />
que dans les années à venir, il n’en soit pas autrement. Une grande concentration de<br />
dispositifs Blu<strong>et</strong>ooth à proximité d’une station est catastrophique pour les<br />
performances de <strong>WLAN</strong>.<br />
8.1.6 Eff<strong>et</strong> des émissions parasites de Blu<strong>et</strong>ooth<br />
Avant de parler des émissions parasites, il s’agit d’en distinguer deux catégories ; les<br />
émissions dans la bande ISM <strong>et</strong> les émissions hors de la bande ISM. Dans le cadre de<br />
169
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
la coexistence, seule les émissions dans la bande ISM peuvent interférer avec <strong>WLAN</strong><br />
<strong>802.11</strong>b, les émissions hors bande ISM ne seront donc pas abordées.<br />
La spécification de Blu<strong>et</strong>ooth impose un masque de transmission qui définit les<br />
valeurs limites des émission parasites :<br />
Figure 103 : Masque de transmission de Blu<strong>et</strong>ooth (source : Agere Systems)<br />
Comme le montre la Figure 103, considérer que la largeur de bande d’un canal est de 1<br />
MHz est valable uniquement au-dessus de –20 dBm. En dessous de –20 dBm<br />
Blu<strong>et</strong>ooth utilise une bande plus large (environ 4 MHz). Les dispositifs Blu<strong>et</strong>ooth<br />
présent sur le marché sont conformes au masque de transmission définit par la norme.<br />
Ce qui ne veut pas dire que la caractéristique réelle d’un ém<strong>et</strong>teur Blu<strong>et</strong>ooth colle<br />
parfaitement au masque, mais qu’elle ne sera en aucun cas au-dessus.<br />
Lors de la simulation le spectre de Blu<strong>et</strong>ooth était conforme à ce qui prescrit dans la<br />
norme. Cependant, comme le montre la Figure 104, le simulateur ém<strong>et</strong> dans une<br />
bande supérieure à 1 MHz en dessous de 20 dBm. Cela influe sur les performances de<br />
<strong>WLAN</strong>.<br />
170
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Figure 104 : Spectre Blu<strong>et</strong>ooth fournit par le simulateur<br />
Figure 105 : Spectre Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong><br />
La Figure 105 représente le spectre des dispositifs Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong> relevé lors<br />
d’une simulation. Bien que le canal utilisé par Blu<strong>et</strong>ooth ne se trouve pas dans la<br />
bande utilisée par <strong>WLAN</strong>, il y a interférence. C<strong>et</strong>te interférence engendre des erreurs<br />
lorsque la puissance du signal <strong>WLAN</strong> est trop faible par rapport à celui émis par<br />
Blu<strong>et</strong>ooth. Les résultats de simulation montre que les émissions parasites sont<br />
responsables d’erreurs lorsque le rapport S/I est inférieur à environ -25 dB.<br />
171
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Figure 106 : FER en fonction du rapport S/I<br />
Figure 107 : Zones de coexistence<br />
172
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
8.1.7 RINEA<br />
8.1.7.1 Introduction<br />
Dans un système de communication classique, les paqu<strong>et</strong>s erronés ne sont pas stockés<br />
<strong>et</strong> l'information qu'ils contiennent n'est pas utilisée. C<strong>et</strong>te information, certes non<br />
exploitable pour l'instant, pourrait le devenir si un paqu<strong>et</strong> identique, lui aussi faux, était<br />
renvoyé. En m<strong>et</strong>tant l'information de ces deux paqu<strong>et</strong>s erronés en commun, on peut<br />
obtenir un paqu<strong>et</strong> correcte. Le débit du système sera donc augmenté.<br />
8.1.7.2 Algorithme<br />
Le principe est de comparer les paqu<strong>et</strong>s erronés identiques (enfin qui devrait l'être<br />
sans les erreurs dues au canal de transmission), voici la marche à suivre :<br />
• Détection d'un paqu<strong>et</strong> erroné avec l'aide du CRC.<br />
• Le paqu<strong>et</strong> erroné est stocké dans une mémoire quelconque au lieu d'être<br />
supprimer comme dans la plus part des systèmes.<br />
• Si la r<strong>et</strong>ransmission est réussie (le contrôle est toujours effectuer grâce au<br />
CRC), alors le paqu<strong>et</strong> précédemment stocké est supprimé <strong>et</strong> on<br />
recommence au point 1. Si par contre, une ou plusieurs nouvelles erreurs<br />
surviennent, le système va tenter de changer les bits qui diffèrent <strong>entre</strong> les<br />
deux paqu<strong>et</strong>s (voir Figure 108). Le système va générer toutes les<br />
possibilités qui existent.<br />
K = nombre de possibilité à tester<br />
I = nombre de bit différent <strong>entre</strong> les deux paqu<strong>et</strong>s<br />
K = 2 I −2<br />
Équation 76<br />
• Le CRC de chaque possibilité doit être calculé pour trouver la bonne<br />
combinaison.<br />
Figure 108 : Représentation de deux paqu<strong>et</strong>s identiques avec 2 bits qui se différencient<br />
173
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
C<strong>et</strong>te algorithme peut se généraliser avec plus de deux paqu<strong>et</strong>s dans les cas où le taux<br />
d'erreur est extrêmement élevé en comparaison avec à la taille des paqu<strong>et</strong>s. Dans ce<br />
cas, l'Équation 76 s'écrit en rajoutant une variable qui est le nombre de paqu<strong>et</strong>s<br />
transmis P.<br />
K=2<br />
I −P<br />
Équation 77<br />
8.1.7.3 Débit réel théorique<br />
Pour estimer le débit réel, il n'est plus possible d'utiliser le développement fait au<br />
chapitre 6.4, car la probabilité qu'un paqu<strong>et</strong> soit bien transmis dépend des paqu<strong>et</strong>s<br />
précédemment envoyés. Le développement est donc différent <strong>et</strong> plus complexe à<br />
comprendre.<br />
Le temps de transmission d'un paqu<strong>et</strong> est T p . Il faut donc nT p temps si on désire<br />
transm<strong>et</strong>tre n paqu<strong>et</strong>s. Maintenant, il faut distinguer plusieurs cas qu'on peut dans un<br />
premier temps différentier :<br />
1) Le premier paqu<strong>et</strong> arrive sans erreurs <strong>et</strong> ne génère pas de r<strong>et</strong>ransmission<br />
donc pas de temps en trop.<br />
2) Si le premier paqu<strong>et</strong> est arrivé avec une ou plusieurs fautes, il existe 3<br />
possibilités avec le deuxième paqu<strong>et</strong> :<br />
a) La r<strong>et</strong>ransmission est correcte, <strong>et</strong> dans ce cas, uniquement le temps<br />
d'une transmission est rajouté.<br />
b) La r<strong>et</strong>ransmission est incorrecte, mais l'algorithme arrive à trouver une<br />
combinaison valide, dans ce cas aussi le temps d'une transmission est<br />
rajouté.<br />
c) La r<strong>et</strong>ransmission du paqu<strong>et</strong> est incorrecte <strong>et</strong> l'algorithme n'a pas<br />
fonctionné (pas de combinaison valide).<br />
3) Si la r<strong>et</strong>ransmission est arrivée avec une ou plusieurs fautes <strong>et</strong> que<br />
l'algorithme n'a pas fonctionné, il existe 3 possibilités avec le deuxième paqu<strong>et</strong>:<br />
a) La r<strong>et</strong>ransmission est correcte, <strong>et</strong> dans ce cas uniquement le temps d'une<br />
transmission est rajouté.<br />
174
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
b) La r<strong>et</strong>ransmission est incorrecte, mais l'algorithme arrive à trouver une<br />
combinaison valide, dans ce cas aussi le temps d'une transmission est<br />
rajouté.<br />
c) La r<strong>et</strong>ransmission du paqu<strong>et</strong> est incorrecte <strong>et</strong> l'algorithme n'a pas<br />
fonctionné (pas de combinaison valide).<br />
Répéter c<strong>et</strong>te méthode jusqu'à obtenir le paqu<strong>et</strong> correcte.<br />
Pour connaître le total de transmission en incluant les temps de r<strong>et</strong>ransmission, il faut<br />
calculer les probabilités de transm<strong>et</strong>tre des paqu<strong>et</strong>s supplémentaires. Dans nos calculs,<br />
nous considérons qu'il n'y a pas de codage supplémentaire mis a part le CRC. La taille<br />
des paqu<strong>et</strong>s est constante <strong>et</strong> égale à N bits.<br />
La probabilité de transm<strong>et</strong>tre une fois chaque paqu<strong>et</strong> est de 100% donc le temps<br />
minimum est de nTp.<br />
La probabilité que le premier paqu<strong>et</strong> soit erroné <strong>et</strong> que la r<strong>et</strong>ransmission soit correcte :<br />
P (1 (1 p)<br />
N)<br />
(1 p)<br />
N<br />
1 = − − ⋅ −<br />
Équation 78<br />
L'Équation 78 se démontre grâce à la variable aléatoire géométrique.<br />
La probabilité de recevoir un paqu<strong>et</strong> <strong>et</strong> sa r<strong>et</strong>ransmission erronées, <strong>et</strong> en plus de<br />
pouvoir corriger les erreurs demande un développement un peu plus complexe.<br />
Quelques étapes supplémentaires sont nécessaires.<br />
Probabilité d'avoir i erreurs dans un paqu<strong>et</strong> k :<br />
P ( i)<br />
k<br />
pi⋅(1−<br />
p)<br />
=<br />
N −i<br />
( N )<br />
Équation 79<br />
L'Équation 79 se démontre avec la variable aléatoire Binomiale.<br />
⋅<br />
i<br />
Probabilité d'avoir i erreurs dans un paqu<strong>et</strong> k <strong>et</strong> j erreurs dans sa r<strong>et</strong>ransmission (k+1).<br />
i+<br />
j 2⋅<br />
Pk<br />
( i)<br />
⋅Pk<br />
+ 1 ( j)<br />
= p ⋅(1−<br />
p)<br />
Équation 80<br />
N −i−<br />
j<br />
( N )( ⋅ N )<br />
⋅<br />
i<br />
j<br />
175
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
L'Équation 80 se démontre grâce à l'Équation 79 qui est multipliée par un paqu<strong>et</strong> <strong>et</strong> sa<br />
r<strong>et</strong>ransmission.<br />
Maintenant, connaissant respectivement deux paqu<strong>et</strong>s avec la probabilité qu'ils ont<br />
d'avoir i <strong>et</strong> j erreurs, il faut calculer la probabilité que les bits erronés soient sur des<br />
positions différentes pour les deux paqu<strong>et</strong>s. C'est la condition essentielle pour que<br />
l'algorithme puisse détecter le paqu<strong>et</strong> sans erreur.<br />
Une hypothèse pour nos calculs est que le nombre d'erreur i+j < N, la probabilité que<br />
c<strong>et</strong>te hypothèse ne soit pas respectée est extrêmement faible même pour des taux<br />
d'erreur très élevés.<br />
Le nombre de combinaisons pour lesquels il y a j erreur dans un paqu<strong>et</strong> de N bits :<br />
( N ) N! i<br />
=<br />
( N i )! i !<br />
Équation 81<br />
L'Équation 81 se démontre grâce à la loi des combinaisons.<br />
−<br />
⋅<br />
Dans un paqu<strong>et</strong> avec i erreurs, l'algorithme fonctionne si les j erreurs de la<br />
r<strong>et</strong>ransmission se situe sur le N-i bits restants.<br />
Nombre de combinaisons pour lesquels i <strong>et</strong> j erreurs ne se trouvent pas sur les mêmes<br />
postions :<br />
( N − ( N i)!<br />
j i −<br />
) =<br />
( N i j)!<br />
j!<br />
− −<br />
Équation 82<br />
L'Équation 82 se démontre grâce à la loi des combinaisons.<br />
⋅<br />
Le nombre de combinaisons qui ont i <strong>et</strong> j erreurs mais qui est corrigible par<br />
l'algorithme :<br />
( N )( ) !<br />
i<br />
⋅ N −<br />
j i =<br />
( N i<br />
N<br />
j)!<br />
i!<br />
j!<br />
− −<br />
Équation 83<br />
L'Équation 83 est la multiplication <strong>entre</strong> l'Équation 82 <strong>et</strong> l'Équation 81.<br />
⋅<br />
⋅<br />
176
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Maintenant avec i <strong>et</strong> j erreurs sur deux paqu<strong>et</strong>s, le nombre total de combinaisons est<br />
utile dans nos calculs <strong>et</strong> est donné par :<br />
( N<br />
N! )( ) 2 i<br />
⋅ N j<br />
=<br />
( N−i)!<br />
⋅(<br />
N−<br />
j)!<br />
⋅i!<br />
⋅j!<br />
Équation 84<br />
L'Équation 84 est le résultat d'une multiplication de deux résultats de combinaison.<br />
Probabilité d'avoir i <strong>et</strong> j erreur <strong>et</strong> de pouvoir corriger en utilisant l'algorithme :<br />
P<br />
corr<br />
= p<br />
i+<br />
j<br />
⋅(1−<br />
p)<br />
2⋅N<br />
−i−<br />
j<br />
!<br />
( N−i−<br />
N<br />
j)!<br />
⋅i!<br />
⋅j!<br />
Équation 85<br />
L'Équation 85 est la multiplication de la division de l'Équation 84 <strong>et</strong> l'Équation 83 par<br />
l'Équation 80.<br />
La probabilité d'avoir des erreurs sur le paqu<strong>et</strong> <strong>et</strong> sa r<strong>et</strong>ransmission <strong>et</strong> que l'algorithme<br />
arrive à les corriger :<br />
P =<br />
2<br />
N N<br />
∑ − j<br />
i<br />
j<br />
= 1<br />
= 1<br />
p<br />
i+<br />
j<br />
⋅(<br />
1−<br />
p)<br />
2⋅N<br />
−i−<br />
j<br />
⋅<br />
N−i−<br />
N !<br />
( j)!<br />
⋅i!<br />
⋅j!<br />
Équation 86<br />
L'Équation 86 est la somme de toutes les erreurs sur les deux paqu<strong>et</strong>s corrigibles.<br />
Avec plus d'un paqu<strong>et</strong> <strong>et</strong> deux r<strong>et</strong>ransmissions, le paqu<strong>et</strong> correct doit être détectable.<br />
Les cas où le paqu<strong>et</strong> n'est pas détectable est très improbable (voir Figure 109) <strong>et</strong> si le<br />
taux d'erreur devenait suffisamment grand pour qu'il devienne probable, l'algorithme<br />
serait alors trop lent.<br />
177
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
probabilité de transm<strong>et</strong>tre plus 3<br />
paqu<strong>et</strong>s<br />
100%<br />
80%<br />
60%<br />
40%<br />
20%<br />
0%<br />
0% 2% 4% 6% 8% 10%<br />
taux d'erreur par bit<br />
Figure 109 : probabilité de transm<strong>et</strong>tre plus de 3 paqu<strong>et</strong>s de 1000 bits pour corriger les erreurs<br />
La probabilité de devoir transm<strong>et</strong>tre un troisième paqu<strong>et</strong> pour pouvoir corriger les<br />
erreurs :<br />
P3 = ( 1−(1−<br />
p)<br />
N)<br />
2−P<br />
Équation 87<br />
L'Équation 87 est la différence <strong>entre</strong> la probabilité d'avoir 2 paqu<strong>et</strong>s faux <strong>et</strong> la<br />
probabilité de pouvoir corriger les fautes de ces deux paqu<strong>et</strong>s.<br />
2<br />
Le temps total de transmission pour n paqu<strong>et</strong>s :<br />
T = nTp + nT P +<br />
1 + nTP2<br />
2nTP3<br />
Équation 88<br />
Le débit en considérant i bits d'informations par paqu<strong>et</strong> :<br />
D=<br />
i⋅n<br />
nTp( 1+<br />
P1 + P2<br />
+ 2⋅P3<br />
)<br />
Équation 89<br />
La Figure 110 montre le débit réel avec l'algorithme <strong>et</strong> correction automatique. Ces<br />
paqu<strong>et</strong>s ont une taille de 150 bits <strong>et</strong> n'ont pas de codage (uniquement un CRC pour la<br />
détection d'erreur). C<strong>et</strong>te simulation a été faite avec Matlab <strong>et</strong> les sources se trouvent<br />
en annexe de ce document.<br />
178
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
1<br />
0.9<br />
0.8<br />
0.7<br />
0.6<br />
0.5<br />
0.4<br />
0.3<br />
0.2<br />
0.1<br />
0<br />
0 0.005 0.01 0.015 0.02 0.025 0.03 0.035 0.04 0.045 0.05<br />
Taux d'erreur par bit<br />
Figure 110 : Débit réel théorique d'une transmission de paqu<strong>et</strong> de 150 bits avec utilisation des<br />
paqu<strong>et</strong>s erronés (Matlab)<br />
179
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
8.1.7.4 Simulation<br />
Une simulation perm<strong>et</strong> de valider les calculs du chapitre 8.1.7.3. Un programme en<br />
JAVA qui simule la transmission de paqu<strong>et</strong>s pour un taux d'erreur donné. Le code<br />
source de ce programme est mis en annexe de ce document. La Figure 111 montre le<br />
résultat de c<strong>et</strong>te simulation.<br />
1<br />
0.8<br />
Débit réel<br />
0.6<br />
0.4<br />
0.2<br />
0<br />
0 0.01 0.02 0.03 0.04 0.05<br />
Taux d'erreur par bits<br />
Figure 111 : Débit réel simulé d'une transmission de paqu<strong>et</strong> de 150 bits avec utilisation des<br />
paqu<strong>et</strong>s erronés (JAVA)<br />
Les courbes théoriques <strong>et</strong> simulées sont presque identiques. La Figure 112 montre<br />
l'écart de débit réel qu'il y a <strong>entre</strong> les deux courbes.<br />
0.9%<br />
0.8%<br />
Différence <strong>entre</strong> de débit réel<br />
(pourcentage) théorique <strong>et</strong><br />
simulé<br />
0.7%<br />
0.6%<br />
0.5%<br />
0.4%<br />
0.3%<br />
0.2%<br />
0.1%<br />
0.0%<br />
0.0% 1.0% 2.0% 3.0% 4.0% 5.0%<br />
Taux d'erreur par bit<br />
Figure 112 : Ecart <strong>entre</strong> les courbes de la simulation <strong>et</strong> de la théorie pour 150 bits<br />
180
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
8.1.7.5 Ressource nécessaire<br />
L'inconvénient majeur de c<strong>et</strong>te algorithme est le nombre de combinaison à tester 1 . Elle<br />
augmente vite avec le nombre de bit par paqu<strong>et</strong> <strong>et</strong> avec le taux d'erreur par bit. La<br />
Figure 113 illustre le nombre de combinaison.<br />
Nombre de combinaison<br />
500<br />
400<br />
300<br />
200<br />
100<br />
0<br />
0.00% 0.05% 0.10% 0.15% 0.20%<br />
Taux d'erreur par bit<br />
Figure 113 : Nombre de combinaison moyenne pour une transmission avec des paqu<strong>et</strong>s de<br />
1496 bits en connaissant le taux d'erreur<br />
Une première solution pour améliorer l'efficacité de l'algorithme est d'utiliser un<br />
système de majorité à partir de la réception du troisième paqu<strong>et</strong> erroné. En cas de bits<br />
qui différent <strong>entre</strong> les paqu<strong>et</strong>s, il y a forcément 2 des 3 paqu<strong>et</strong>s qui ont la même valeur<br />
de bit à la même position ce qui la rend majoritaire (ce qui ne veut pas forcément dire<br />
juste). Pour trouver la combinaison correcte, l'algorithme commence par tester la<br />
combinaison de la majorité ce qui augmente considérablement la probabilité de<br />
trouver le paqu<strong>et</strong> correct.<br />
1 C'est-à-dire le nombre de CRC à calculer<br />
181
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Figure 114 : représentation d'une correction par la technique de la majorité<br />
L'exemple de la Figure 114 n'est pas plausible. Les deux premiers paqu<strong>et</strong>s étaient<br />
suffisant pour r<strong>et</strong>rouver le paqu<strong>et</strong> d'origine. Pour qu'un troisième paqu<strong>et</strong> soit<br />
r<strong>et</strong>ransmis, il faut que les deux premiers paqu<strong>et</strong>s aient le même bit faux sur la même<br />
position. La technique de la majorité ne va donc jamais fonctionner à la première<br />
tentative.<br />
8.1.7.6 Algorithme informatique<br />
La procédure Reception_paqu<strong>et</strong> contrôle si le paqu<strong>et</strong> est correctement arrivé <strong>et</strong><br />
appelle la procédure Test_stock en cas d'erreur.<br />
Reception_paqu<strong>et</strong> :<br />
i = 0<br />
Boucle<br />
{<br />
Boucle<br />
{<br />
Paqu<strong>et</strong>_correct = Faux<br />
réception du paqu<strong>et</strong> ( i)<br />
Si le CRC est correct<br />
{<br />
vider le tableau_paqu<strong>et</strong><br />
Paqu<strong>et</strong>_correct = Vrai<br />
182
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
}<br />
Si le CRC est incorrect<br />
{<br />
Stocker le paqu<strong>et</strong> (i) dans tableau_paqu<strong>et</strong><br />
Si Test_stock est correcte<br />
{<br />
vider le tableau_ paqu<strong>et</strong><br />
Paqu<strong>et</strong>_correct = Vrai<br />
}<br />
}<br />
}<br />
Boucle tant que Paqu<strong>et</strong>_correct = Faux<br />
i = i + 1<br />
}<br />
Boucle tant que i < nombre de paqu<strong>et</strong> à transm<strong>et</strong>tre<br />
La procédure Test_stock contrôle si suffisamment de paqu<strong>et</strong> sont stockés pour tenter<br />
la correction. Si une correction est possible, elle appelle la procédure Test_recup. Elle<br />
cherche les bits déterminés (identique pour tous les paqu<strong>et</strong>s stockés) <strong>et</strong> nondéterminés<br />
(qui diffèrent <strong>entre</strong> les paqu<strong>et</strong>s stockés)<br />
Test_stock :<br />
Si tableau_paqu<strong>et</strong> contient moins de 2 éléments<br />
{<br />
R<strong>et</strong>ourne faux<br />
}<br />
j = 0<br />
Boucle<br />
{<br />
j = j + 1<br />
tableau_contrôle (j) = contrôle_bit_identique<br />
}<br />
Boucle tant que j < taille_bit_paqu<strong>et</strong><br />
Paqu<strong>et</strong>_test = Inscrit tous les bits qui son probablement corrects <strong>et</strong> laisse vide les autres<br />
R<strong>et</strong>ourne Test_recup<br />
183
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
La procédure Test_recup contrôle toutes les combinaisons possibles (utilise la<br />
récursivité). K est une variable global, donc la même pour tous les appelles récursifs.<br />
Test_recup :<br />
K = pointe sur le prochain bit non déterminé (utilise tableau_contrôle)<br />
Si K pointe sur un bit<br />
{<br />
Paqu<strong>et</strong>_test (k) = 0<br />
Si Test_recup alors r<strong>et</strong>ourne Vrai<br />
Paqu<strong>et</strong>_test (k) = 1<br />
Si Test_recup alors r<strong>et</strong>ourne Vrai<br />
}<br />
Si K ne pointe plus sur rien donc plus aucun bit non déterminé<br />
{<br />
r<strong>et</strong>ourne le CRC (Vrai si correct <strong>et</strong> faux si incorrect)<br />
}<br />
8.1.7.7 Mesures<br />
Les mesures, avec Blu<strong>et</strong>ooth comme parasite, donne en moyenne un nombre de bits<br />
faux par paqu<strong>et</strong> bien au delà de 600. Ceci s'explique par le fait qu'un paqu<strong>et</strong> Blu<strong>et</strong>ooth<br />
perturbe pendant un temps équivalent égal à environ 600 bits transmis à 11 Mbit/s. Il<br />
est donc impossible de pouvoir tester toutes les possibilités pour trouver le CRC<br />
correct. L'utilisation de l'algorithme RINEA n'augmente malheureusement pas le débit<br />
en cas de perturbation Blu<strong>et</strong>ooth.<br />
184
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
8.2 Changement de technologie ?<br />
8.2.1 Technologies <strong>et</strong> bandes de fréquences<br />
Une réponse au problème de la coexistence <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong>b <strong>et</strong> Blu<strong>et</strong>ooth serait<br />
d’utiliser des réseaux informatiques sans-fils travaillant hors de la bande ISM 2,4 GHz.<br />
C’est par exemple le cas du standard <strong>802.11</strong>a ou de HiperLAN, qui tout deux<br />
fonctionnent à des fréquences au-dessus de 5 GHz. Bien que c<strong>et</strong>te idée puisse paraître<br />
comme idéale puisqu’elle élimine toutes interférence avec Blu<strong>et</strong>ooth, elle risque<br />
cependant d’être victime d’un phénomène déjà rencontrer par les technologies<br />
utilisant des bandes de fréquences libres.<br />
Le phénomène est le suivant : généralement les bandes de fréquence libres, comme les<br />
bandes ISM, appartiennent d’abord à l’armée ou au monde médical <strong>et</strong> scientifique.<br />
Lorsque que l’industrie a la possibilité d’y développer des applications, elle sont<br />
coûteuses <strong>et</strong> peu répandues. A ce stade là, il n’y a en général pas de problèmes de<br />
coexistence car les différentes technologies travaillant dans la même bande de<br />
fréquences sont très peu répandues. Mais, <strong>et</strong> c’est ce qui c’est vu avec Blu<strong>et</strong>ooth <strong>et</strong><br />
<strong>WLAN</strong> <strong>802.11</strong>b, lorsque le matériel <strong>et</strong> les techniques commencent à être mieux<br />
maîtrisées <strong>et</strong> étendues, les prix de développement baissent. C<strong>et</strong>te baisse des coûts,<br />
ainsi que le marché potentiel ouvert par une technologie, entraîne l’apparition de<br />
plusieurs types de dispositifs travaillant dans la même bande de fréquences, pas<br />
toujours compatibles <strong>et</strong> qui peuvent alors interférer <strong>entre</strong> eux.<br />
La leçon à tirer de ce phénomène est qu’actuellement aucune bande de fréquences<br />
libre n’est à l’abri de l’apparition d’une nouvelle technologie pouvant venir interférer.<br />
Et cela malgré les efforts des organismes de normalisation <strong>et</strong> de réglementation<br />
comme l’IEEE ou la FCC. Le choix d’une technologie pour la réalisation d’un réseau<br />
informatique sans-fils doit donc s’appuyer sur d’autres critères que l’encombrement de<br />
la bande de fréquence dans laquelle il évolue.<br />
8.2.2 Quels réseaux choisir ?<br />
Lorsqu’il s’agit d’installer un réseau informatique sans-fils, différentes solutions sont<br />
offertes au utilisateurs. Les critères de décision pour le choix d’une technologie sansfils<br />
sont pour la plupart semblables à ceux pour un réseau câblé traditionnel ; débit,<br />
couverture, coût, interopérabilité… Voici un bref aperçu des principaux standards<br />
disponibles où bientôt disponibles :<br />
185
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
8.2.2.1 <strong>802.11</strong>a<br />
<strong>802.11</strong>a est perçu comme le successeur de <strong>802.11</strong>b. Bien qu’à l’heure actuelle, c<strong>et</strong>te<br />
norme soit encore très peu développée, elle offre néanmoins d’excellentes perspectives<br />
en ce qui concerne l’avenir des réseaux <strong>WLAN</strong>. Son point fort est son débit brut de 54<br />
Mbps, perm<strong>et</strong>tant une qualité de service suffisante pour la transmission de données<br />
temps-réels (VoIP, streaming vidéo).<br />
Autre point fort en comparaison avec <strong>802.11</strong>b est que dans la bande de fréquence<br />
définie par la norme, il est possible de définir 12 réseaux indépendants sans aucune<br />
interférences. Avec <strong>802.11</strong>b, le nombre de réseaux différents est de quatre dans le cas<br />
des législations les plus souples (3 dans la majorité des pays industrialisés).<br />
Figure 115 : Spectre de tous les réseaux <strong>802.11</strong>a disponibles<br />
C<strong>et</strong>te caractéristique de la bande de fréquence est intéressante car <strong>802.11</strong>a dispose<br />
d’une couverture moins étendue que <strong>802.11</strong>b. En eff<strong>et</strong> alors que <strong>802.11</strong>b est capable<br />
de fournir une communication à 11 Mbps <strong>entre</strong> deux dispositifs distant de 100 mètres,<br />
à puissance équivalente <strong>802.11</strong>a n’excède pas 9 Mbps à 50 mètres. Un débit de 36 à 54<br />
Mbps est garantit pour autant que le réseaux reste dans un rayon de 15 mètres. C<strong>et</strong>te<br />
baisse de performances en comparaison avec <strong>802.11</strong>b s’explique par le fait que les<br />
fréquences utilisées ne sont plus dans la bande ISM 2,4 GHz, mais dans une bande de<br />
fréquences supérieures à 5 GHz. Comme démontrer dans le modèle de propagation<br />
des ondes électromagnétique (voir chapitre sur les modèles théoriques), la perte<br />
d’intensité du signal est proportionnel à sa longueur d’onde. Pour obtenir une<br />
couverture identique à celle fournie par <strong>802.11</strong>b, il faut donc disposer de quatre<br />
réseaux <strong>802.11</strong>a. Il faut encore relever que pour les deux normes, le nombre de<br />
186
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
stations par réseaux ne devrait pas dépasser 20 à 30, sans quoi les performances<br />
risquent d’être en baisse.<br />
Figure 116 : Comparaison <strong>entre</strong> les couvertures <strong>802.11</strong>b <strong>et</strong> <strong>802.11</strong>a<br />
Il n’est pas envisageable d’augmenter la puissances des appareils pour deux raisons<br />
évidentes. La première raison est certainement celle qui est le plus facilement<br />
contournable, il s’agit de la réglementation imposée par certain états à propos des<br />
puissances d’émission. La seconde raisons est que <strong>802.11</strong>a doit rester une technologie<br />
à faible consommation afin qu’elle puisse être intégrée aux ordinateurs portables <strong>et</strong><br />
autres équipements alimentés par batteries.<br />
Tout en étant un rival de <strong>802.11</strong>b, <strong>802.11</strong>a est en dans le même temps complémentaire<br />
<strong>et</strong> peu se greffer sur un réseau <strong>802.11</strong>b existant. <strong>802.11</strong>a perm<strong>et</strong> alors de faire<br />
fonctionner des applications plus gourmandes en bande passante (VoIP, vidéo), tout<br />
en gardant les tâches traditionnelles (transfert de fichiers, e-mail, surf) sur l’ancien<br />
réseau. Etant donné que les deux types de réseaux fonctionnent à des fréquences<br />
différentes, ils peuvent parfaitement cohabiter dans le même environnement. Bon<br />
nombre de fabricants de carte <strong>WLAN</strong> proposent des cartes réseaux <strong>et</strong> des points<br />
d’accès dual-band pouvant travailler dans les deux types de réseaux.<br />
187
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Bien que <strong>802.11</strong>a ne soit pas encore très répandu, c<strong>et</strong>te technologie va très<br />
certainement rencontrer un énorme succès. Les équipements sont maintenant (2003) à<br />
des prix très compétitifs ; moins de 300$ pour un point d’accès dual-band<br />
<strong>802.11</strong>b/<strong>802.11</strong>a avec quatre ports Ethern<strong>et</strong> 10/100, 125$ pour une carte pcmcia, soit<br />
environ deux fois le prix des équipement <strong>802.11</strong>b. Mais les prix devrait rapidement se<br />
rapprocher de ceux des équipements <strong>802.11</strong>b.<br />
8.2.2.2 <strong>802.11</strong>g<br />
Comme pour <strong>802.11</strong>a, <strong>802.11</strong>g offre un débit de 54 Mbps grâce une modulation<br />
OFDM (Orthogonal Frequency Division Multipexing). Cependant <strong>802.11</strong>g travaille<br />
dans la bande ISM 2,4 GHz, ce qui lui donne l’avantage d’avoir des réseaux ayant une<br />
couverture environ quatre fois plus importante 1 . Cependant c<strong>et</strong>te avantage est<br />
déprécié par le fait qu’il n’est possible de définir que trois réseaux dans l’ensemble de<br />
la bande ISM.<br />
<strong>802.11</strong>g est compatible avec la norme existante <strong>802.11</strong>b, ce qui n’est pas le cas de<br />
<strong>802.11</strong>a. Il suffit de remplacer un point d’accès pour obtenir un réseau <strong>802.11</strong>g, même<br />
si celui-ci contient des stations équipées de carte réseaux <strong>802.11</strong>b.<br />
La technologie <strong>802.11</strong>g n’est pas disponibles à l’heure actuelle, mais les premiers<br />
dispositifs devraient voir le jours durant l’année 2003. Le coût des équipements devrait<br />
rapidement rejoindre les prix actuels des équipement <strong>802.11</strong>b, pour autant que <strong>802.11</strong>a<br />
n’occupe d’ici là l’ensemble du marché.<br />
8.2.2.3 HiperLAN<br />
HiperLAN est une norme européenne utilisant une bande de fréquence à 5 GHz (5.15<br />
– 5.3 GHz) <strong>et</strong> une autre bande de fréquence à 17 GHz (17.1 – 17.3 GHz). Utilisant la<br />
même couche physique que <strong>802.11</strong>a (modulation OFDM), elle offre un débit de 54<br />
Mbps dans sa version la plus aboutie (HiperLAN/2).<br />
HiperLAN est en train de perdre la bataille face à <strong>802.11</strong>a pour les réseaux sans-fils<br />
sur le sol européen, aux Etats-Unis <strong>802.11</strong>a n’a pas de concurrent à l’heure actuelle.<br />
Les organismes de contrôle européen (ETSI) souhaitent que les deux systèmes soient<br />
1 Distances deux fois plus importante à puissance égale des ém<strong>et</strong>teurs, ce qui donne une surface environ<br />
quatre fois supérieure en pratique.<br />
188
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
compatibles, mais <strong>802.11</strong>a est, contrairement à HiperLAN, déjà disponible <strong>et</strong> risque<br />
fort d’étouffer son concurrent.<br />
8.2.2.4 Home RF<br />
Home RF a été introduit par le groupe Home Radio Frequency Working Group (WG)<br />
qui comprend notamment des <strong>entre</strong>prises comme Intel, Compaq, HP, IBM ou<br />
Microsoft. Les performances de Home RF sont très proches des performances de<br />
<strong>WLAN</strong> <strong>802.11</strong>b, avec un débit de 10 Mbps <strong>et</strong> une protée de 50 à 100m. Home RF<br />
utilise aussi la bande ISM à 2,4 Ghz, ce qui pose des problèmes de cohabitation avec<br />
Blu<strong>et</strong>ooth, <strong>802.11</strong>b <strong>et</strong> <strong>802.11</strong>g.<br />
Actuellement, peu d’équipements sont disponibles <strong>et</strong> il ne semble pas que Home RF<br />
puisse rivaliser avec Wi-Fi.<br />
189
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
190
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
9 Interférences <strong>entre</strong><br />
réseaux <strong>WLAN</strong><br />
191
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
9.1 Description du problème<br />
Lorsque deux réseaux <strong>WLAN</strong> distincts cohabitent dans le même environnement, les<br />
performances de chacun deux sont amoindries. Bien que ce problème soit<br />
indépendant du problème de la coexistence avec Blu<strong>et</strong>ooth, la mise en place d’un<br />
réseau performant ne peut se faire sans considérer les interférences <strong>entre</strong> dispositifs<br />
<strong>WLAN</strong>.<br />
La norme <strong>802.11</strong> définit 14 canaux 1 , il est donc possible de concevoir deux (ou plus)<br />
réseaux <strong>WLAN</strong> fonctionnant à des fréquences différentes dans le même<br />
environnement. Quel peuvent être les conséquences d’une telle réalisation ?<br />
Il est aussi possible d’envisager deux réseaux basés sur infrastructure, dont les point<br />
d’accès couvrent la même zone <strong>et</strong> utilise des fréquences identiques. Quel sera alors le<br />
comportement des équipements <strong>et</strong> quelles conséquences cela aura sur le trafic ?<br />
9.2 Interférences <strong>entre</strong> réseaux utilisant des canaux différents<br />
9.2.1 Description<br />
Comme le montre la Figure 117, les canaux définis par la norme ne sont séparés que<br />
par 5 MHz. La largeur de bande d’un canal étant d’environ 20 MHz, deux canaux<br />
adjacents occupent nécessairement les même fréquences.<br />
Figure 117 : Canaux définis par la norme <strong>802.11</strong> (www.cisco.com)<br />
1 Certain états ont apporté des restrictions dans l’utilisation de la bande ISM 2,4GHz. Au USA, le<br />
nombre de canaux disponibles est de 11. En France, seul 4 canaux sont disponibles.<br />
192
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
En réalité, dire que la largeur d’un canal <strong>WLAN</strong> est de 20 MHz n’est pas tout à fait<br />
juste. En eff<strong>et</strong>, le 99% de l’énergie du signal est contenue dans une bande de fréquence<br />
d’environ 15 MHz. En considérant des canaux d’environ 15 MHz, il est possible de<br />
prévoir que seul les trois canaux précédents <strong>et</strong> suivants le canal concerné seront<br />
susceptibles de créer des interférences capables d’engendrer des erreurs.<br />
Le simulateur utilisé pour traiter de manière théorique le problème de la coexistence<br />
peut perm<strong>et</strong>tre de quantifier les problèmes dus aux interférences <strong>entre</strong> dispositifs<br />
utilisant des canaux différents. La simulation présente dans ce chapitre reprend donc<br />
les hypothèses émises dans la conception du modèle théorique, notamment en ce qui<br />
concerne le modèle de propagation des ondes électromagnétiques.<br />
9.2.2 Simulation<br />
La simulation ne traite que la partie physique, le schéma ci-dessous présente le modèle<br />
utilisé. Grâce à c<strong>et</strong>te simulation, il sera possible de déterminer qu’elles sont les<br />
dégradations sur les communications lorsque des canaux différents sont utilisés dans le<br />
même environnement.<br />
Figure 118 : Schéma de la simulation<br />
C<strong>et</strong>te simulation traite le cas particulier où deux dispositifs communiquent <strong>entre</strong> eux<br />
alors qu’un troisième dispositif ém<strong>et</strong> sur un canal différent. Evidemment, les réseaux<br />
193
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
rencontrés dans la réalité sont plus complexes car ils sont, en général, constitués d’un<br />
nombre plus élevé de dispositifs. Mais le but de la simulation est avant de tout de<br />
déterminer qu’elle est la nature des problèmes <strong>et</strong> utiliser les résultats de la simulations<br />
pour en tirer un constat plus général.<br />
La Figure 119 présente les résultats de trois séries de mesures pour un débit de 11<br />
MHz. Les courbes du graphiques délimitent les zones où les interférences entraînent<br />
des erreurs sur les bits transmis. Les zones colorées représentent donc les distances<br />
pour lesquels les trames sont erronées. Les séries de mesures effectuées sont les<br />
suivantes :<br />
1. 1 canal d’écart <strong>entre</strong> les dispositifs communiquant <strong>et</strong> le dispositif<br />
perturbateur.<br />
(canal 5 pour la communication, canal 6 pour la perturbation)<br />
2. 2 canaux d’écart.<br />
(canal 4 pour la communication, canal 6 pour la perturbation)<br />
3. 3 canaux d’écart.<br />
(canal 3 pour la communication, canal 6 pour la perturbation)<br />
Figure 119 : Interférence <strong>entre</strong> dispositifs <strong>WLAN</strong> <strong>802.11</strong><br />
194
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Les courbes dessinées sur le graphique sont une approximation du comportement réel<br />
des dispositifs durant la simulation. En eff<strong>et</strong>, les points relevés sur le graphique<br />
représente un endroit, désigné par les distances <strong>entre</strong> ém<strong>et</strong>teurs <strong>et</strong> récepteur, pour<br />
lequel le pourcentage de trames erronées est comprise <strong>entre</strong> 0 <strong>et</strong> 100%. Les résultats<br />
obtenus lors de la simulation montre que les interférences n’entraînent pas<br />
nécessairement une communication entièrement fausse ou entièrement juste, mais<br />
qu’à certain endroit seule une partie des trames sont erronées. La zone où seule une<br />
partie des trames sont fausses n’est pas représentée sur le graphique. Il faut cependant<br />
préciser que c<strong>et</strong>te zone ne s’étend que sur environ 10 à 15% autour des limites<br />
indiquées sur le graphique.<br />
Les limites indiquées sur le graphe de la Figure 119 sont presque des droites. Le<br />
pourcentage de trames erronées dépend donc d’une constantes. C<strong>et</strong>te constante est le<br />
rapport <strong>entre</strong> le signal utilisé pour la transmission des trames <strong>et</strong> le signal qui interfère<br />
(rapport S/I). Les rapports S/I limites pour un débit de 11 MHz sont les suivants :<br />
• Pour un écart de 1 canal : 6 dB (± 1 dB)<br />
• Pour un écart de 2 canaux : -2 dB (± 1 dB)<br />
• Pour un écart de 3 canaux : -27 dB (± 2 dB)<br />
Les ± 1 ou 2 dB d’écart représentent la marge dans laquelle seule une partie des trames<br />
sont fausses. Part exemple pour les 6 dB lorsqu’il y a un canal d’écart, il faut<br />
comprendre qu’en dessous de 5 dB il n’y a aucune trame erronée <strong>et</strong> qu’au dessus de 7<br />
dB toutes les trames sont erronées. Il faut de plus relever qu’<strong>entre</strong> 5 <strong>et</strong> 7 dB de rapport<br />
S/I, le nombre d’erreurs par trame erronée n’est que de quelques bits (3 à 6 bits). Ce<br />
constat peut-être intéressant dans la cadre de la conception de mécanismes de<br />
corrections d’erreurs. Cependant il reste à déterminer quel serait le gain réelle, tant au<br />
niveau performance qu’au niveau économique, que pourrait apporter de tels<br />
mécanismes dans le cadre de <strong>WLAN</strong> <strong>802.11</strong>.<br />
195
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Aucune erreur n’a été détectée pour un écart de 4 canaux. Comme le montre la Figure<br />
120, les spectres produits par chacun des ém<strong>et</strong>teurs <strong>WLAN</strong> ne chevauchent pas. Il n’a<br />
donc aucune interférence <strong>entre</strong> les deux transmissions.<br />
Figure 120 : Spectre de deux émissions <strong>WLAN</strong> avec 4 canaux d’écart<br />
9.2.3 Analyse des résultats<br />
Les résultats de la simulation perm<strong>et</strong>tent de tirer un certain nombre de constats<br />
intéressants concernant l’évaluation des performances <strong>et</strong> la réalisation des réseaux<br />
<strong>WLAN</strong> <strong>802.11</strong>.<br />
• L’utilisation par deux réseaux <strong>WLAN</strong> distincts de canaux proches (c’est-àdire<br />
séparer que par 1, 2 ou 3 canaux) engendre des interférences. Ces<br />
interférences sont la cause, dans le cas ou le rapport <strong>entre</strong> la puissance des<br />
ém<strong>et</strong>teurs (rapport S/I) est trop défavorable, d’erreurs dans les trames<br />
envoyées.<br />
• Le "rapport S/I limite", c’est-à-dire à partir duquel apparaissent des<br />
erreurs, est constant pour un écart <strong>entre</strong> canaux donné. Le rapport S/I<br />
dépend directement de la puissance des ém<strong>et</strong>teurs (dans le cas où les<br />
puissances d’émission seraient différentes dans les deux réseaux) <strong>et</strong> des<br />
distances <strong>entre</strong> les ém<strong>et</strong>teurs <strong>et</strong> le récepteur.<br />
196
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
• Bien que la simulation de l’utilisation de plusieurs canaux adjacents n’est<br />
pas été réalisée, il est évident que les performances n’en seront que plus<br />
dégradées.<br />
9.3 Interférence <strong>entre</strong> réseaux utilisant le même canal<br />
Si deux réseaux <strong>WLAN</strong> utilisent le même canal dans le même environnement avec<br />
différents SSID, le débit réel mesuré est de plus ou moins 50% du débit maximum.<br />
C<strong>et</strong>te dégradation du débit s'explique par la méthode d'accès au canal utilisée par<br />
<strong>802.11</strong>; CSMA/CA. Le principe de CSMA/CA est qu'une station voulant ém<strong>et</strong>tre<br />
écoute le canal de transmission <strong>et</strong> si il est occupé, il rem<strong>et</strong> sa transmission à plus tard.<br />
Comme tous les dispositif utilisent le même canal ils peuvent donc détecter de<br />
l'activité sur celui-ci. On obtient donc une situation dans laquelle la bande est utilisée<br />
par des stations n'appartenant pas au même réseau. La bande est donc partagée par<br />
deux réseaux <strong>et</strong> les performances de chacun d'eux sont dégradées.<br />
Les dégradations sont proportionnelles à l'activité de chaque réseaux. Par exemple en<br />
imaginant deux réseaux possédant le même trafic <strong>et</strong> que ce trafic est important, alors<br />
les dégradations pour chacun des réseaux seront proches de 50%. Dans le cas où le<br />
trafic est peu important, les dégradations seront inférieures à 50%, voir quasiinexistantes<br />
dans le cas d'un trafic très faible.<br />
C<strong>et</strong>te explication peut-être généralisée à plus de deux réseaux <strong>WLAN</strong> utilisant le<br />
même canal. Dans ces conditions les dégradations seront beaucoup plus importantes.<br />
Par conséquent, il est vivement déconseillé de faire cohabiter plusieurs réseaux<br />
utilisant le même canal<br />
197
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
9.4 Conclusion<br />
Bien qu'il soit possible de faire cohabiter plusieurs 1 réseaux <strong>WLAN</strong> dans le même<br />
environnement, certaines précautions doivent d'être observées afin d'obtenir des<br />
performances acceptables.<br />
• Il vivement déconseillé d'utiliser le même canal. Les dégradations<br />
peuvent dans des cas défavorables atteindre 50% (sans compter, la<br />
fenêtre de contention dynamique) du débit pour chacun des réseaux.<br />
• Eviter de réaliser des réseaux utilisant des canaux adjacents. En dessous<br />
de quatre canaux d'écart les performances peuvent être réduites, dans<br />
certaines conditions il est même possible que le réseau soit totalement<br />
inutilisable.<br />
1 Utilisant des SSID différents <strong>et</strong> ne pouvant donc pas communiquer directement <strong>entre</strong> eux.<br />
198
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
199
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
10 Documentation<br />
Logiciel<br />
200
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
10.1 LAN Evaluation<br />
LanEval est un outil d'évaluation des cartes PRISM dans un réseau <strong>WLAN</strong>. Il perm<strong>et</strong><br />
de connaître le débit réel au niveau de la couche MAC ou de la couche application.<br />
Pour pouvoir utiliser ce programme, il faut disposer de deux ordinateurs. Le premier<br />
dispositif servira à la transmission des données (voir Figure 121). Le deuxième, pour<br />
sa part, réceptionne les données <strong>et</strong> affiche les statistiques (voir Figure 122).<br />
Figure 121 : Fenêtre de transmission pour le logiciel LanEval<br />
201
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Figure 122 : Fenêtre de l'ém<strong>et</strong>teur pour le logiciel LanEval<br />
LanEval fonctionne avec le protocole UDP (couche 4) qui n'établit pas de connexion<br />
<strong>et</strong> opère au niveau des datagrammes. Les datagrammes UDP sont numérotés. Ce<br />
logiciel a comme avantage qu'il a été fait par le fabriquant du chip s<strong>et</strong>, ceci perm<strong>et</strong><br />
d'avoir accès à la couche MAC 1 .<br />
10.2 N<strong>et</strong>work Stumbler<br />
N<strong>et</strong>Stumbler est un outil perm<strong>et</strong>tant de trouver des AP à portée d'une carte Wi-Fi. Il<br />
donne aussi l'adresse MAC, le SSID <strong>et</strong> le canal utilisé. Il est aussi possible de<br />
déterminer si les transmissions sont sécurisées (WEP) ainsi que le rapport signal/bruit.<br />
A la base, ce logiciel était utilisé par des pirates informatiques pour trouver des AP. Ce<br />
logiciel fonctionne en scannant tous les canaux les uns après les autres.<br />
1 On peut normalement de connaître les erreurs de transmission dues à la ligne<br />
202
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Toutes les capacités de c<strong>et</strong> outil peuvent être utilisées uniquement avec quelques cartes<br />
<strong>WLAN</strong>. En eff<strong>et</strong>, avec quelques autres cartes, certaines fonctionnalités sont<br />
inaccessibles.<br />
Figure 123 : Fenêtre de N<strong>et</strong>Stumbler avec une carte 3Com (le numéro de canal n'est pas<br />
visible avec c<strong>et</strong>te carte)<br />
Dans le cas de la Figure 123, le calibrage est bien évidemment faux. Un rapport<br />
signal/bruit de –60 dB alors que l'AP nommé Revedor2 ne se trouve qu'à 1 mètre en<br />
est l'exemple. Ce programme, qui a l'avantage d'être gratuit, doit être pris avec des<br />
pinc<strong>et</strong>tes.<br />
10.3 PRISM Benchmark Pro<br />
Ce logiciel, aussi fournit par Intersil, est utilisé pour connaître le débit d'un transfert de<br />
fichier sous Windows. Sa méthode de fonctionnement est très simple; il copie, sur un<br />
répertoire partagé du réseau, un fichier de 10 Mbit/s <strong>et</strong> il chronomètre le temps dont il<br />
a besoin. Il répète un certain nombre fois c<strong>et</strong>te procédure pour être sûr des valeurs<br />
obtenues <strong>et</strong> donne une moyenne.<br />
203
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Figure 124 : Fenêtre du logiciel PRISM Benchmark Pro<br />
10.4 Airopeek<br />
Airopeek est un sniffer de trame <strong>802.11</strong> fait par WildPack<strong>et</strong>s. Ce logiciel demande une<br />
carte <strong>WLAN</strong> spécial pour pouvoir sniffer la couche MAC. Voici la liste des cartes<br />
<strong>WLAN</strong> pour le <strong>802.11</strong>b reconnu par Airopeek :<br />
• Cisco Systems 340 <strong>et</strong> 350 Series PC Card<br />
• Symbol Spectrum24 11 Mbps DC PC Card<br />
• Nortel N<strong>et</strong>works e-mobility <strong>802.11</strong> <strong>WLAN</strong> PC Card<br />
• Intel PRO/Wireless 2011 LAN PC Card<br />
• 3Com Airconnect 11 Mbps <strong>WLAN</strong> PC Card<br />
• Lucent ORiNOCO PC card<br />
Dans notre cas, une carte Orinoco était à disposition. Le firmware a dû être modifier<br />
pour que c<strong>et</strong>te carte soit accepté.<br />
204
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Airopeek supporte aussi les protocoles de haut niveau comme par exemple TCP/IP,<br />
AppleTalk, IPX …<br />
Le grand avantage de Airopeek est qu'il perm<strong>et</strong> de déterminer si des erreurs se sont<br />
produites au niveau de la couche MAC. Il est aussi possible d'analyser en détail les<br />
erreurs qui sont survenues 1 .<br />
Ce programme fonctionne, à peu de chose près, comme la plus part des analyseurs<br />
standards. Il offre la possibilité de visionner en détail les trames ou de connaître<br />
uniquement les statistiques globales.<br />
Figure 125 : Capture détaillée d'un paqu<strong>et</strong> avec Airopeek<br />
Figure 126 : Statistique globale d'une transmission <strong>802.11</strong>b<br />
1 possibilité de connaître si les erreurs arrivent par paqu<strong>et</strong> ou non.<br />
205
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
10.5 Bluel<strong>et</strong><br />
Bluel<strong>et</strong> est un logiciel qui fonctionne pour les dispositifs Blu<strong>et</strong>ooth de chez Gericom.<br />
Il perm<strong>et</strong> de transférer des fichiers <strong>et</strong> d'accéder à réseau grâce au protocole PPP. Pour<br />
utiliser ces deux services, un station doit faire l'office de serveur <strong>et</strong> l'autre celle de<br />
client. Le serveur devra lancer un processus puis le client pourra alors se connecter sur<br />
celui là. Ce programme est utilisé pour générer du trafic Blu<strong>et</strong>ooth.<br />
Figure 127 : fenêtre de gestion du logiciel Bluel<strong>et</strong><br />
206
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
207
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
11 Conclusions<br />
208
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
C<strong>et</strong>te étude a prouvé que la présence d’ém<strong>et</strong>teurs Blu<strong>et</strong>ooth perturbe les<br />
communications <strong>entre</strong> dispositifs <strong>WLAN</strong> <strong>802.11</strong>b. Ces perturbations causent des<br />
baisses de performances importantes des réseaux <strong>WLAN</strong>. Faire coexister les deux<br />
technologies nécessite donc certaines précautions :<br />
• Respect d’une certaine distance <strong>entre</strong> les réseaux <strong>WLAN</strong> <strong>et</strong> Blu<strong>et</strong>ooth, afin<br />
d’obtenir un rapport signal sur interférence suffisant (>5dB).<br />
• Eviter d’installer des applications Blu<strong>et</strong>ooth <strong>et</strong> <strong>WLAN</strong> sur le même<br />
ordinateur.<br />
• Les solutions intégrant les deux technologies sur une même carte peuvent<br />
constituer une option intéressante. Cependant, la polyvalence de ce genre de<br />
produit se paie au niveau performances.<br />
Bien qu’elle ne soit pas encore disponible sur le marché, l’AFH (Adaptive Frequency<br />
Hopping) appliqué à Blu<strong>et</strong>ooth est une solution prom<strong>et</strong>teuse qui résout les problèmes<br />
de coexistence pour autant qu’il n’y ait qu’un seul <strong>WLAN</strong> (un canal dans la bande<br />
ISM).<br />
A l’heure actuelle, il n’y a pas de solution idéale au problème de la coexistence <strong>entre</strong><br />
<strong>WLAN</strong> <strong>802.11</strong>b <strong>et</strong> Blu<strong>et</strong>ooth. Mais le problème pourrait perdre de son importance<br />
avec une migration vers <strong>802.11</strong>a (5GHz), cela à condition que c<strong>et</strong>te nouvelle<br />
technologie ne se trouve pas confrontée à une nouvelle technologie parasite.<br />
Yverdon, le 16 décembre 2002<br />
Karl Baumgartner<br />
Jérôme Racloz<br />
209
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
210
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
12 Remerciements<br />
211
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Un très grand merci à Monsieur Marcos<br />
Rubinstein pour avoir proposé, supervisé<br />
<strong>et</strong> pour nous avoir aidé durant c<strong>et</strong>te étude.<br />
Sa motivation <strong>et</strong> ses compétences ont fait<br />
de ce travail une expérience passionnante<br />
<strong>et</strong> très enrichissante.<br />
Merci à Monsieur Heinrich Ryser pour<br />
nous avoir accueilli dans les laboratoires<br />
de METAS <strong>et</strong> grandement aidé nos<br />
mesures.<br />
Merci à Monsieur Lucas Varé <strong>et</strong> Monsieur Christian T<strong>et</strong>tamanti pour leur aide<br />
durant l’installation <strong>et</strong> la configuration des cartes <strong>WLAN</strong> sous Linux.<br />
Merci à Monsieur Albert Richard pour son soutient logistique.<br />
Merci à Monsieur Alessandro Calia pour nous avoir fait partagé ces connaissances de<br />
Matlab.<br />
Merci à Monsieur Cédric Ducommun pour ces conseil en matière de conception<br />
graphique.<br />
Merci à Madame Iulia Kun-Popovici <strong>et</strong> son mari pour leur aide dans le domaine du<br />
traitement des signaux.<br />
Merci à Monsieur Patrick Favre pour ses explications sur les antennes, les masques<br />
de transmission <strong>et</strong> la propagation des ondes.<br />
Merci à Monsieur Marc Ballesteros pour nous avoir découvert <strong>et</strong> fait connaître un<br />
excellent analyseur de trafic.<br />
Merci à l’ensemble de l’équipe de TCOM <strong>et</strong> à la ETR6, pour les bon moments<br />
partagés durant ces 12 semaines.<br />
212
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
213
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
13 Bibliographie<br />
214
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
[BT01] Specification of the Blu<strong>et</strong>ooth System, version 1.1, 2001<br />
[EMRAFH] Eric Meihofer, Enhancing ISM Band Performance Using Adaptive<br />
Frenquency Hopping, décembre 2001<br />
[IEEEAFH] Hongbing Gan & Bihan Treister, Adaptive Frequency Hopping<br />
Implementation Proposals for IEEE 802.15.1/2 WPAN, 2000<br />
[IKIIC] Iulia Kun Popovici, Information <strong>et</strong> Codage, été 2001<br />
[MOBAFH] Mobilian, Adaptive Frequency Hopping: Good Enough?, 2002<br />
[MOBECA] Mobilian, Wi-Fi and Blu<strong>et</strong>ooth: An Examination of <strong>Coexistence</strong><br />
Approaches, 2001<br />
[MRNBT] MarcosRubinstein, Blu<strong>et</strong>ooth, 2001<br />
[MRN<strong>WLAN</strong>] Marcos Rubinstein, Wireless LAN, été 2001<br />
[PAT] Pierre-Louis Aubert, Probabilité & Statistique<br />
[<strong>WLAN</strong>99] Part 11:Wireless LAN Medium Access Control (MAC) and Physical Layer<br />
(PHY) Specification, 1999 Edition<br />
[BHW] Mobile Radio N<strong>et</strong>work de Bernhard H. Walke Second Editioo, 2002<br />
[MCV] On the Throughput of Blu<strong>et</strong>ooth Data Transmission de Valenti, <strong>Robert</strong> and<br />
Reed, 2002<br />
[BAK] Reliability of Blu<strong>et</strong>ooth de Boris A. Krassi<br />
[NGFM] Interference in the 2.4 GHz ISM Band: Impact on the Blu<strong>et</strong>ooth Access<br />
Control Performance de Nada Golmie <strong>et</strong> Frederic Mouveaux<br />
[ASNA] Impact of Space-Time Block Codes on <strong>802.11</strong> N<strong>et</strong>work Throughput,<br />
Anastasios Stamoulis <strong>et</strong> Naofal Al-Dhahir, 2002<br />
215
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
[JSBT] Etude d'un analyseur de protocole pour réseau Blu<strong>et</strong>ooth de J. St<strong>et</strong>tler, 2001<br />
[KSS] TCP/IP de Karanjit S. Siyan<br />
[MJCR] Markus Jaton <strong>et</strong> Christian Roubaty, Modulations, 2001<br />
[MJJAVA] Markus Jaton, JAVA, 2001<br />
[CCRR] Performance of IEEE <strong>802.11</strong> <strong>WLAN</strong>s in a Blu<strong>et</strong>ooth Environment de Carla<br />
Chiasserini <strong>et</strong> Ramesh Rao<br />
216
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
Tables des figures<br />
FIGURE 1 : COMPLEMENTARITE ENTRE BLUETOOTH ET WIRELESS LAN (SOURCE : MOBILIAN,<br />
GARTNER)......................................................................................................................... 12<br />
FIGURE 2 : ELEMENTS DE L'ARCHITECTURE <strong>802.11</strong> ................................................................... 20<br />
FIGURE 3 : STRUCTURE DU PROTOCOLE <strong>802.11</strong>......................................................................... 23<br />
FIGURE 4 : FORMAT D’UNE TRAME MAC (SOURCE : [<strong>WLAN</strong>99]) ............................................ 25<br />
FIGURE 5 : FORMAT DU CHAMPS FRAME CONTROL (SOURCE : [<strong>WLAN</strong>99]) ............................. 25<br />
FIGURE 6 : ENVOI DE DONNEE AVEC QUITTANCEMENT (SOURCE : LAWRENCE LANDWEBER, JUN<br />
MURAI) ............................................................................................................................. 30<br />
FIGURE 7 : STATION CACHEE..................................................................................................... 32<br />
FIGURE 8 : TRAME RTS (SOURCE : [<strong>WLAN</strong>99]) ....................................................................... 32<br />
FIGURE 9 : TRAME CTS (SOURCE : [WL99])............................................................................. 33<br />
FIGURE 10 : FONCTIONNEMENT DE RTS/CTS (SOURCE : LAWRENCE LANDWEBER, JUN MURAI)<br />
.......................................................................................................................................... 33<br />
FIGURE 11 : PCF ET DCF (SOURCE : LAWRENCE LANDWEBER, JUN MURAI)............................ 34<br />
FIGURE 12 : EFFET DE L’INTERFERENMCE AVEC UN SIGNAL DE BANDE ETROITE ....................... 41<br />
FIGURE 13 : PRINCIPE DE FONCTIONNEMENT DE DSSS (SOURCE : IEEE <strong>802.11</strong>) ...................... 42<br />
FIGURE 14 : SPECTRE D’UN SIGNAL MODULE EN DSSS (SOURCE : IEEE <strong>802.11</strong>)...................... 42<br />
FIGURE 15 : TRAME PLCP EN FHSS (SOURCE : [<strong>WLAN</strong>99]) ................................................... 45<br />
FIGURE 16 : TRAME PLCP (SOURCE : [<strong>WLAN</strong>99])................................................................... 46<br />
FIGURE 17 : PILE DE PROTOCOLE DU NOYAU BLUETOOTH [SOURCE<br />
HTTP://TP.BLUETOOTH.FREE.FR ] ....................................................................................... 50<br />
FIGURE 18 : COMPARAISON ENTRE BLUETOOTH ET LE MODELE OSI ......................................... 51<br />
FIGURE 19 : REPRESENTATION DES SAUTS DE FREQUENCE ........................................................ 52<br />
FIGURE 20 : MODULATION GFK [BT01].................................................................................... 53<br />
FIGURE 21 : TABLEAU DES CLASSES DE PUISSANCE ................................................................... 53<br />
FIGURE 22 : REPRESENTATION D'UN PICONET............................................................................ 55<br />
FIGURE 23 : SCATTERNET OU UN DISPOSITIF JOUE LE ROLE D'ESCLAVE DANS LES DEUX PICONETS<br />
.......................................................................................................................................... 55<br />
FIGURE 24 : REPRESENTATION DE L'ADRESSE BD_ADDR ........................................................ 56<br />
FIGURE 25 : CODAGE FEC 1/3 [BT01] ...................................................................................... 57<br />
FIGURE 26 : REGISTRE A DECALAGE GENERATEUR DE CODE HAMMING POUR FEC 2/3 [BT01] 57<br />
FIGURE 27 : TRANSMISSION SUR 1 SLOT [MRNBT] .................................................................. 58<br />
FIGURE 28 : TRANSMISSION SUR 5 SLOTS [MRNBT]................................................................. 58<br />
FIGURE 29 : REPRESENTATION NORMAL D'UN PAQUET BLUETOOTH.......................................... 60<br />
217
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
FIGURE 30 : LE FORMAT DE L'ACCESS CODE.............................................................................. 60<br />
FIGURE 31 : SEQUENCE DU PREAMBULE [BT01]........................................................................ 61<br />
FIGURE 32 : FORMAT DE L'ENTETE DE PAQUET .......................................................................... 62<br />
FIGURE 33 : TABLEAU DES TYPES DE PAQUET [BT01] ............................................................... 63<br />
FIGURE 34 : FORMAT DE LA CARGAISON D'UN PAQUET FHS [BT01] ......................................... 64<br />
FIGURE 35 : REPRESENTATION DU CHAMP SR ........................................................................... 65<br />
FIGURE 36 : REPRESENTATION DU CHAMP SP............................................................................ 65<br />
FIGURE 37 : REPRESENTATION DU CHAMP PAGE SCAN MODE .................................................... 66<br />
FIGURE 38 : ENTETE DE CARGAISON SUR 1 BYTE (PREND 1 SLOT) [BT01] ................................. 69<br />
FIGURE 39 : ENTETE DE CARGAISON SUR 2 BYTES (PREND 3 OU 5 SLOTS) [BT01] ..................... 69<br />
FIGURE 40 : DIAGRAMME DES ETATS DE LINK CONTROLLER [BT01]........................................ 71<br />
FIGURE 41 : SCHEMA BLOC DE LA PROCEDURE INQUIRY............................................................ 72<br />
FIGURE 42 : PHASE DE TRANSMISSION PUIS D'ECOUTE DU SOUS-ETAT INQUIRY......................... 73<br />
FIGURE 43 : REPRESENTATION DES TEMPS D'ECOUTE DU SOUS-ETAT INQUIRY SCAN ................ 74<br />
FIGURE 44 : SUITE DE SEQUENCES POUR LA PROCEDURE PAGE .................................................. 75<br />
FIGURE 45 : SPECTRE DE <strong>WLAN</strong> <strong>802.11</strong>B EN DSSS ................................................................. 79<br />
FIGURE 46 : SPECTRE DE BLUETOOTH....................................................................................... 79<br />
FIGURE 47 : BLUETOOTH ET <strong>WLAN</strong> <strong>802.11</strong> DANS LE DOMAINE TEMPOREL .............................. 81<br />
FIGURE 48 : PROBABILITE D’INTERFERENCE ENTRE <strong>WLAN</strong> <strong>802.11</strong>B ET BLUETOOTH............... 83<br />
FIGURE 49 : PROBABILITE D’INTERFERENCE ENTRE <strong>WLAN</strong> <strong>802.11</strong>B ET DEUX DISPOSITIFS<br />
BLUETOOTH ...................................................................................................................... 84<br />
FIGURE 50 : COMPARAISON ENTRE LIAISON SCO ET ACL ........................................................ 85<br />
FIGURE 51 : TABLEAU DES HOPS POUR LES DIFFERENTS TYPES DE PAQUETS.............................. 86<br />
FIGURE 52 : PROBABILITE D’INTERFERENCE POUR LES LIAISON ACL SYMETRIQUES................. 87<br />
FIGURE 53 : PROBABILITE D’INTERFERENCE POUR LES LIAISON ACL ASYMETRIQUES .............. 87<br />
FIGURE 54 : ENVOI ET ACQUITTEMENT D’UNE TRAME AVEC CSMA ......................................... 89<br />
FIGURE 55 : TABLEAU DU DEBIT REEL DE <strong>WLAN</strong> <strong>802.11</strong>B ....................................................... 90<br />
FIGURE 56 : DEBIT REEL EN PRESENCE DE BLUETOOTH............................................................. 92<br />
FIGURE 57 : DESCRIPTION DE LA MESURE ................................................................................. 96<br />
FIGURE 58 : RESULTAT DE LA MESURE (SOURCE : MOBILIAN CORP.)........................................ 97<br />
FIGURE 59 : SPECTRE – INTERFERENCE ENTRE BLUETOOTH ET <strong>WLAN</strong> <strong>802.11</strong>B ...................... 99<br />
FIGURE 60 : SCHEMA CONCEPTUEL DU DRIVER-LEVEL SWITCHING (SOURCE : MOBILIAN)..... 100<br />
FIGURE 61 : DIFFERENCE ENTRE PROPAGATION ISOTROPIQUE ET NON-ISOTROPIQUE .............. 106<br />
FIGURE 62 : INTENSITE DU SIGNAL DANS UNE PIECE (SOURCE : [<strong>WLAN</strong>99]) .......................... 111<br />
FIGURE 63 : MODELE DE PROPAGATION A 2,44 GHZ............................................................... 113<br />
FIGURE 64 : SCHEMA DU MODELE D’INTERFERENCE ............................................................... 114<br />
FIGURE 65 : DECALAGE D’UN SLOT DU SIGNAL DU RECEPTEUR............................................... 118<br />
218
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
FIGURE 66 : MODIFICATION DE LA SEQUENCE DE HOP............................................................. 118<br />
FIGURE 67 : SIMULATEUR ....................................................................................................... 120<br />
FIGURE 68 : PARAMETRAGE DES PERTES DES DIFFERENTS DISPOSITIFS ................................... 120<br />
FIGURE 69 : CHANGEMENT DE LA VALEUR DU BUFFER............................................................ 121<br />
FIGURE 70 : SPECTRE DU SIGNAL REÇU PAR LE RECEPTEUR <strong>WLAN</strong>........................................ 122<br />
FIGURE 71 : SCHEMA DE LA SIMULATION ................................................................................ 123<br />
FIGURE 72 : TAUX DE TRAMES ERRONEES (P <strong>WLAN</strong> = 1W) ........................................................ 124<br />
FIGURE 73 POURCENTAGE DE TRAMES ERRONEES................................................................... 125<br />
FIGURE 74 : FER EN FONCTION DU RAPPORT S/I ..................................................................... 125<br />
FIGURE 75 : FER EN FONCTION DE LA DIMENSION DES TRAMES .............................................. 126<br />
FIGURE 76 : FER EN FONCTION DU DEBIT <strong>WLAN</strong>................................................................... 127<br />
FIGURE 77 : COMPORTEMENT AVEC DEUX DISPOSITIFS BLUETOOTH....................................... 128<br />
FIGURE 78 : PROBABILITE DE TRANSMISSION CORRECTE DE L’ENTETE BLUETOOTH<br />
CONNAISSANT LE TAUX D’ERREUR .................................................................................. 136<br />
FIGURE 79 : REPRESENTATION DE LA CARGAISON EN DH1 ..................................................... 137<br />
FIGURE 80 : POURCENTAGE DU DEBIT REEL DES PAQUETS DH1 EN CONNAISSANT LE TAUX<br />
D'ERREUR PAR BIT............................................................................................................ 138<br />
FIGURE 81 : REPRESENTATION DE LA CARGAISON EN DH3 ..................................................... 139<br />
FIGURE 82 : POURCENTAGE DU DEBIT REEL DES PAQUETS DH3 EN CONNAISSANT LE TAUX<br />
D'ERREUR PAR BIT............................................................................................................ 140<br />
FIGURE 83 : REPRESENTATION DE LA CARGAISON EN DH3 ..................................................... 140<br />
FIGURE 84 : POURCENTAGE DU DEBIT REEL DES PAQUETS DH5 EN CONNAISSANT LE TAUX<br />
D'ERREUR PAR BIT............................................................................................................ 141<br />
FIGURE 85 : COMPARAISON DES DEBITS SYMETRIQUE ENTRE PAQUET DH AVEC UN TAUX<br />
D'ERREUR ........................................................................................................................ 141<br />
FIGURE 86 : POURCENTAGE DU DEBIT REEL DES PAQUETS DM1 EN CONNAISSANT LE TAUX<br />
D'ERREUR PAR BIT............................................................................................................ 143<br />
FIGURE 87 : POURCENTAGE DU DEBIT REEL DES PAQUETS DM3 EN CONNAISSANT LE TAUX<br />
D'ERREUR PAR BIT............................................................................................................ 144<br />
FIGURE 88 : POURCENTAGE DU DEBIT REEL DES PAQUETS DM5 EN CONNAISSANT LE TAUX<br />
D'ERREUR PAR BIT............................................................................................................ 145<br />
FIGURE 89 : COMPARAISON ENTRE LA SIMULATION ET LA THEORIE POUR LES PAQUETS DH1 . 146<br />
FIGURE 90 : COMPARAISON ENTRE LA SIMULATION ET LA THEORIE POUR LES PAQUETS DM1 147<br />
FIGURE 91 : REPRESENTATION DU PREAMBULE PLCP............................................................. 148<br />
FIGURE 92 : DEBIT REEL DE LA COUCHE MAC......................................................................... 149<br />
FIGURE 93 : REPRESENTATION DU DEBIT UTILE D'APRES LE TAUX D'ERREUR EN <strong>WLAN</strong> AVEC<br />
UNE TRANSMISSION A 11 MBIT/S..................................................................................... 151<br />
219
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
FIGURE 94 : CHAMBRE ANECHOÏQUE (SOURCE : ACOUSTIC GROUP) ....................................... 154<br />
FIGURE 95 : ONDES REFLECHIES PAR LE SOL ........................................................................... 155<br />
FIGURE 96 : SCHEMA DE MESURE............................................................................................ 156<br />
FIGURE 97 : RESULTATS DE LA MESURE EN PLEIN AIR ............................................................. 157<br />
FIGURE 98 : CHAMBRE ANECHOÏQUE DE METAS ................................................................... 158<br />
FIGURE 99 : RESULTATS DE MESURE DU SPECTRE DE BLUETOOTH .......................................... 159<br />
FIGURE 100 : COMPARAISON ENTRE LES RESULTATS DE LA SIMULATION ET DE LA MESURE.... 160<br />
FIGURE 101 : DEBIT EN FONCTION DE LA DIMENSION DES TRAMES.......................................... 166<br />
FIGURE 102 : POURCENTAGE DE TRAMES ERRONEES AVEC PLUSIEURS DISPOSITIFS BLUETOOTH<br />
........................................................................................................................................ 168<br />
FIGURE 103 : MASQUE DE TRANSMISSION DE BLUETOOTH (SOURCE : AGERE SYSTEMS) ........ 170<br />
FIGURE 104 : SPECTRE BLUETOOTH FOURNIT PAR LE SIMULATEUR......................................... 171<br />
FIGURE 105 : SPECTRE BLUETOOTH ET <strong>WLAN</strong> ...................................................................... 171<br />
FIGURE 106 : FER EN FONCTION DU RAPPORT S/I ................................................................... 172<br />
FIGURE 107 : ZONES DE COEXISTENCE .................................................................................... 172<br />
FIGURE 108 : REPRESENTATION DE DEUX PAQUETS IDENTIQUES AVEC 2 BITS QUI SE<br />
DIFFERENCIENT ............................................................................................................... 173<br />
FIGURE 109 : PROBABILITE DE TRANSMETTRE PLUS DE 3 PAQUETS DE 1000 BITS POUR CORRIGER<br />
LES ERREURS ................................................................................................................... 178<br />
FIGURE 110 : DEBIT REEL THEORIQUE D'UNE TRANSMISSION DE PAQUET DE 150 BITS AVEC<br />
UTILISATION DES PAQUETS ERRONES (MATLAB) ............................................................. 179<br />
FIGURE 111 : DEBIT REEL SIMULE D'UNE TRANSMISSION DE PAQUET DE 150 BITS AVEC<br />
UTILISATION DES PAQUETS ERRONES (JAVA) ................................................................. 180<br />
FIGURE 112 : ECART ENTRE LES COURBES DE LA SIMULATION ET DE LA THEORIE POUR 150 BITS<br />
........................................................................................................................................ 180<br />
FIGURE 113 : NOMBRE DE COMBINAISON MOYENNE POUR UNE TRANSMISSION AVEC DES<br />
PAQUETS DE 1496 BITS EN CONNAISSANT LE TAUX D'ERREUR ......................................... 181<br />
FIGURE 114 : REPRESENTATION D'UNE CORRECTION PAR LA TECHNIQUE DE LA MAJORITE ...... 182<br />
FIGURE 115 : SPECTRE DE TOUS LES RESEAUX <strong>802.11</strong>A DISPONIBLES ..................................... 186<br />
FIGURE 116 : COMPARAISON ENTRE LES COUVERTURES <strong>802.11</strong>B ET <strong>802.11</strong>A......................... 187<br />
FIGURE 117 : CANAUX DEFINIS PAR LA NORME <strong>802.11</strong> (WWW.CISCO.COM) ............................ 192<br />
FIGURE 118 : SCHEMA DE LA SIMULATION .............................................................................. 193<br />
FIGURE 119 : INTERFERENCE ENTRE DISPOSITIFS <strong>WLAN</strong> <strong>802.11</strong>............................................ 194<br />
FIGURE 120 : SPECTRE DE DEUX EMISSIONS <strong>WLAN</strong> AVEC 4 CANAUX D’ECART ...................... 196<br />
FIGURE 121 : FENETRE DE TRANSMISSION POUR LE LOGICIEL LANEVAL................................. 201<br />
FIGURE 122 : FENETRE DE L'EMETTEUR POUR LE LOGICIEL LANEVAL..................................... 202<br />
220
<strong>Coexistence</strong> <strong>entre</strong> <strong>WLAN</strong> <strong>802.11</strong> <strong>et</strong> Blu<strong>et</strong>ooth<br />
K. Baumgartner <strong>et</strong> J. Racloz<br />
FIGURE 123 : FENETRE DE NETSTUMBLER AVEC UNE CARTE 3COM (LE NUMERO DE CANAL N'EST<br />
PAS VISIBLE AVEC CETTE CARTE)..................................................................................... 203<br />
FIGURE 124 : FENETRE DU LOGICIEL PRISM BENCHMARK PRO.............................................. 204<br />
FIGURE 125 : CAPTURE DETAILLEE D'UN PAQUET AVEC AIROPEEK ......................................... 205<br />
FIGURE 126 : STATISTIQUE GLOBALE D'UNE TRANSMISSION <strong>802.11</strong>B...................................... 205<br />
FIGURE 127 : FENETRE DE GESTION DU LOGICIEL BLUELET ..................................................... 206<br />
221