Université de la Manouba
ECOLE NATIONALE DES SCIENCES DE
L'INFORMATIQUE

RAPPORT
de Mémoire de Fin d'Etudes

Présenté en vue de l'obtention du titre
d'INGÉNIEUR EN INFORMATIQUE

par
Ahmed Ayadi

SUJET :

Extensions du simulateur Omnet++ pour la validation de mécanismes de
transmission multimédia dans les réseaux sans fils IEEE 802.11

Organisme : Projet Planète INRIA -- Sophia Antipolis

Nom du responsable : Dr. Walid Dabbous

Encadré par : Dr. Thierry Turletti

Supervisé par : Pr. Abdelfetteh Belghith

Adresse : 2004 route des lucioles BP 93 06902 Sophia Antipolis France Tél : +33 4 92 38 77 77 Fax: +33 4 92 38 77 65

Dédicace

Je dédie ce travail
A ma mère
A mon père
A mes frères
A ma soeur
A toute ma famille
A mes chers amis.

Ahmed

Remerciement

Ces travaux de mémoire de fin d'étude se sont déroulés au sein du projet Planète à l'INRIA Sophia Antipolis.

Je remercie Monsieur Walid Dabbous le chef du projet, de m'y avoir accueilli et donné les moyens de mener à bien mes travaux. Je remercie vivement mon encadrant Monsieur Thierry Turletti pour sa disponibilité et ses précieux conseils qui m'a permis d'enrichir mon travail, je le remercie également pour son soutien tout au long du déroulement de mon projet.

Je suis reconnaissant à Monsieur Abdelfettah Belghith Professeur à l'école nationale des sciences de l'informatique d'avoir accepté d'être superviseur de mon travail.

Je tiens aussi à adresser ma gratitude à toutes les personnes qui m'ont aidé pendant la préparation de ce travail, je pense ici à Monsieur Diego Dujovne doctorant à l'équipe Planète.

Je tiens à remercier profondément l'ensemble des stagiaires de l'équipe Amir Krifa, Mehdi Msekni, Mohamed Karim Sbai, Jayoung Choi, Mouna Abdelmomen, Naveed Ben Rais avec lesquels j 'ai eu des échanges scientifiques et culturels pendant toute la durée du projet.

Je ne saurais terminer ces remerciements sans penser aux membres du jury pour l'honneur qu'ils m'ont fait d'avoir voulu examiner et évaluer cette modeste contribution et à toute personne qui a contribué, directement ou indirectement, à l'achèvement de ce travail.

Résumé

Résumé

Le présent rapport a été élaboré dans le cadre du projet de fin d'études pour l'obtention du diplôme d'ingénieur en informatique. Ce travail consiste à implémenter de nouveaux modules dans le simulateur OMNET++ afin de simuler de nouvelles approches permettant d'améliorer la qualité de transmission vidéo dans le réseau IEEE 802.11. Après une description des protocoles des couches liaisons de donnés et physiques du standard 802.11, nous présentons les algorithmes proposés pour la sélection du débit de transmission physique. Nous présentons ensuite la transmission vidéo dans les réseaux sans fils et la nouvelle approche basé sur le Leader. Enfin, nous présentons les résultats de nos simulations réalisés au cours de ce projet.

Mot clés : Réseaux Locaux sans fils IEEE 802.11, Sélection du débit de transmission physique, Protocoles temps réel RTP/RTCP, Transmission multimédia dans les réseaux locaux sans fils.

Abstract

This report was elaborate within the framework of the graduation project for obtaining the diploma of computer engineer. This work consists in implementing new modules on OMNET++ simulator to simulate new approach for improving quality of video transmission over IEEE 802.11 networks. After a short description of physical and link layer, we present algorithms proposed for selecting physical rate. Then, we present video transmission over IEEE 802.11 wireless networks and the new approach based on Leader. Finally, we show results of our simulations.

Key words: IEEE 802.11, Wireless LAN, 802.11 MAC/PHY Layer, Physical Rate Selection Mechanisms, Real Time protocols, Multimedia Transmission in WLANs.

Tables des matières

Introduction générale 1

Présentation de l'organisme d'accueil 3

1. INRIA 3

2. L'unité de Recherche INRIA Sophia Antipolis 3

3. Le projet Planète 3

Chapitre 1 : Etat de l'art 4

Introduction 4

1. Introduction à la norme IEEE 802.11 5

1.1. La couche PHY IEEE 802.11 5

1.2. Les différents modèles de propagation 6

1.2.1. Les modèles à grande échelle 6

1.2.1.1. Le modèle Free-Space 6

1.2.1.2. Le modèle Two-Ray 7

1.2.1.3. Le modèle Shadowing 7

1.2.2. Les modèles à petite échelle « fading » 8

1.2.3. Calcul de la probabilité d'erreur de bit BER Bit Error Rate 8

1.2.4. Calcul de la probabilité d'erreur de paquet PER Packet Error Rate 8

1.2.4.1. Distribution uniforme de l'erreur 8

1.2.4.2. Distribution d'erreur non uniforme 9

1.3. La couche MAC 802.11 9

1.3.1. Les modes opératoires de IEEE 802.11 10

1.3.1.1. Le mode infrastructure 11

1.3.1.2. Le mode ad hoc 11

1.3.2. Les algorithmes d'adaptation du débit physique 11

1.3.2.1. Le protocole Auto Rate Feedback (ARF) 11

1.3.2.2. Le protocole Receiver Based Auto Rate (RBAR) 11

1.3.2.3. Le protocole Adaptative Auto Rate Feedback (AARF) 12

2. La transmission video dans les réseaux IEEE 802.11 14

2.1. Les protocoles temps réels 14

2.1.1. Le protocole Real-time Transport Protocole (RTP) 14

2.1.2. Le protocole Real-time Transport Controle Protocole (RTCP) 14

2.1.2.1. Les fonctions de RTCP 14

2.1.2.2. Les paquets RTCP 15

2.2. La transmission multipoint sur IEEE 802.11 16

2.2.1. Le protocole LEP (Leader Election Protocol) 16

2.2.2. Le protocole LB-ARF (Leader Based-ARF) 17

2.2.3. Le protocole LBMS (Leader Based Multicast Services) 17

3. Le simulateur OMNET ++ 18

3.1. Architecture de OMNET++ 18

3.2. La librairie MF 18

3.3. La librairie INET 18

3.3.1. La couche PHY 19

3.3.2. La couche MAC 19

3.3.3. La couche IP 19

3.3.4. La couche RTP 19

3.3.5. La couche Application 19

Conclusion 19

Chapitre 2 : Analyse & Spécification 21

Introduction 21

1. La problématique 21

2. Les besoins fonctionnels 21

2.1. Environnement physique 21

2.2. Les fonctionnalités 21

2.2.1 Les besoins de simulations 21

2.2.2. Au niveau de la couche Physique 22

2.2.3. Au niveau de la couche MAC 22

2.2.4. Au niveau de la couche RTP 22

2.2.5. Au niveau de la couche Application 22

3. Les besoins non fonctionnels 22

4. Diagramme de cas d'utilisation 23

4.1. Définition du système 23

4.1.1 Le simulateur OMNET++ 23

4.1.2. La couche PHY 24

4.1.3. La couche MAC 25

4.1.4. La couche RTP 26

Conclusion 26

Chapitre 3 : Conception 27

Introduction 27

1. L'architecture globale 27

1.1. L'interface réseau IEEE 802.11 27

1.1.1. L'interface réseau IEEE 802.11 de la librairie MF 27

1.1.2. L'interface réseau IEEE 802.11 de la librairie INET 27

1.2 La couche RTP/RTCP 28

2. Diagramme de classes 28

2.1. L'interface réseau IEEE 802.1 1a de la librairie MF 28

2.1.1. La classe Mac8021 1a 30

2.1.2. La classe SnrEval80211a 31

2.1.3. La classe Decider80211a 32

2.2. L'interface réseau IEEE 802.1 1a de la librairie INET 34

2.2.1 Le diagramme des classes de la couche PHY 34

2.2.1.1. La classe Ieee80211aRadio 36

2.2.1.2. La classe Ieee802 11 aRadioModel 36

2.2.1.3. La classe IReceptionModel 37

2.2.1.4. La classe TransmissionMode 37

2.2.2 Le diagramme de classes de la couche MAC 38

2.2.2.1. La classe Ieee80211aMAC 39

2.2.2.2. La classe Ieee8021 1MacLBMS 39

2.2.2.3. La classe Ieee8021 1MacLBMSnonAP 40

2.3. La couche RTP/RTCP 40

2.3.1. La classe RTPEndSystemModel 42

2.3.2. La classe RTCPEndSystemModel 42

2.3.3. La classe RTPParticipantInfo 43

2.3.4. La classe RTPProfile 44

2.3.5. La classe RTPPayloadSender 45

2.3.6. La classe RTPPayloadReceiver 45

2.4. La classe RTPApplication 45

3. Diagrammes de séquences 46

3.1. Calcul de la puissance reçue 46

3.2. Calcul de la durée de transmission 47

3.3. Calcul de PER 47

3.4. La transmission vidéo 48

Conclusion 49

Chapitre 4 : Réalisation 50

Introduction 50

1. Environnement de travail 50

1.1. Environnement matériel 50

1.2. Environnement logiciel 50

1.3. Installation des différentes librairies 51

1.3.1. Installation de Omnet++ 51

1.3.2. Installation de INET 52

1.3.3. Installation de IT++ 52

1.3.4. Intégration de la couche RTP 53

2. Simulations et Résultats 53

2.1 Comparaison entre les différents modèles de propagation physique 53

2.2 Comparaison entre les deux algorithmes d'adaptation du débit physique 56

2.3 Comparaison entre le multicast standard et l'approche Leader 56

3. Difficultés rencontrés 58

4. Etat courant du travail 58

5. Chronogrammes 59

Conclusion 59

Conclusion & Perspective 60

Bibliographie 61

Glossaire 63

Annexe A : Les formats des paquets RTP et RTCP 65

1. RTP 65

1.1. Rôle 65

1.2. Format de l'entête RTP 66

2. RTCP 66

2.1. Rôle 66

2.2. Format des paquets 66

Annexe B : Le fichier masques d'erreur 70

Annexe C : Le fichier omnetconfig 71

Annexe D : Le fichier makemakefile 73

Liste des figures

Figure 1.1 Le fonctionnement de CSMA/CA avec RTS/CTS [Van Steyvoort, 06] 10

Figure 1.2 Le débit de transmission physique RBAR et ARF [Holland et al., 01] 12

Figure 1.3 Comparaison entre les deux approches ARF et AARF [Manshaei, 05] 12

Figure 1.4 Le débit moyen avec les trois différents algorithmes [Manshaei, 05] 13

Figure 2.1 Les cas d'utilisation du simulateur OMNET++ 23

Figure 2.2 Les cas d'utilisation des modèles physiques 24

Figure 2.3 Les cas d'utilisation de la MAC IEEE 802.11 25

Figure 2.4 Les cas d'utilisation de la couche RTP 26

Figure 3.1 Le module Nic80211a 27

Figure 3.2 Les composants du module Ieee8021 1aNicSTA 28

Figure 3.3 Les composants du module RTPLayer 28

Figure 3.4 Diagramme de classes de la couche PHY de la librairie MF 29

Figure 3.5 La classe Mac8021 1a 30

Figure 3.6 La classe SnrEvala 31

Figure 3.7 Le module SnrEval8021 1a 32

Figure 3.8 La classe Decider8021 1a 33

Figure 3.9 Le module Decider8021 1a 34

Figure 3.10 Diagramme de classes de la couche PHY de la librairie INET 35

Figure 3.11 La classe Ieee8021 1aRadio 36

Figure 3.12 Le module Ieee8021 1aRadio 36

Figure 3.13 La classe Ieee8021 1aRadioModel 37

Figure 3.14 La classe IReceptionModel 37

Figure 3.15 La classe TransmissionMode 37

Figure 3.16 Diagramme de classes de la couche MAC de INET 38

Figure 3.17 La classe Ieee80211aMAC 39

Figure 3.18 La classe Ieee8021 1MacLBMS 40

Figure 3.19 La classe Ieee8021 1MacLBMSnonAP 40

Figure 3.20 Diagramme de classes de la couche RTP/RTCP 41

Figure 3.21 La classe RTPEndSystemModel 42

Figure 3.22 La classe RTCPEndSystemModel 43

Figure 3.23 La classe RTPPaticipantInfo 44

Figure 3.24 La classe RTPProfile 44

Figure 3.25 La classe RTPPayloadSender 45

Figure 3.26 La classe RTPPayloadReceiver 45

Figure 3.27 La classe RTPApplication 46

Figure 3.28 Le module RTPApplication 46

Figure 3.29 Diagramme de séquences du calcul de la puissance reçue 47

Figure 3.30 Diagramme de séquences du calcul de la durée de transmission 47

Figure 3.31 Diagramme de séquences du calcul du PER 48

Figure 3.32 Transmission d'un flux vidéo 49

Figure 4.1 Scénario d'un réseau IEEE 802.11 en mode infrastructure 54

Figure 4.2 PER en fonction de la distance 55

Figure 4.3 Influence du fading sur la perte des paquets 55

Figure 4.4 Scénario avec un réseau Ad hoc 56

Figure 4.5 Comparaison entre les deux approches ARF et AARF 56

Figure 4.6 Scénario de transmission de la vidéo dans un réseau IEEE 802.11 57

Figure 4.7 Chronogramme du projet 59

Liste des tableaux

Tableau 1.1 Caractéristiques des différentes couches physiques IEEE 802.11 [Manshaei, 05] 6 Tableau 1.2 Les valeurs typiques de Path loss Exponent et Shadowing Variance

[Khosroshahy, 06] 8

Tableau 4.1 Configuration de l'ordinateur de développement 50

Tableau 4.2 Paramètres de configuration 54

Tableau 4.3 Les paramètres du modèle Two-Ray 54

Tableau 4.4 Les paramètres du modèles Shadowing 54

Tableau 4.5 Les paramètres de configuration du fading 55

Tableau 4.6 Le taux de perte des paquets 57

Introduction générale

Aujourd'hui, nous assistons à une évolution de l'Internet en nombre d'utilisateurs. Parmi les facteurs de cette évolution se trouve le succès des réseaux sans fil 802.11. Les réseaux IEEE 802.11 deviennent de plus en plus populaires car ils permettent aux utilisateurs de se connecter à l'Internet à un prix abordable avec une bande passante relativement importante et aussi la possibilité de se déplacer sans être déconnecté. De plus, de nos jours les cartes réseau sans fil IEEE 802.11 sont déployées dans la majorité des technologies comme les PDAs et les laptops.

En parallèle, les techniques de communication multimédia ont aussi évolué avec les nouveaux algorithmes de compression et de codage. Ainsi, de nombreuses applications multimédia deviennent accessibles à partir des réseaux sans fil. Mais ils présentent encore des obstacles au déploiement. Les problèmes majeurs de ces réseaux sont le taux de perte et la variation de délai sachant que les applications multimédia sont très exigeantes. Une solution évidente pour optimiser l'utilisation de la bande passante et améliorer la qualité de la vidéo consiste à transmettre la vidéo en multipoint à un ensemble d'utilisateurs.

Mais l'utilisation du multipoint standard présente trois problèmes principaux. Le premier est l'impossibilité d'adapter la fenêtre de collision suivant l'état du réseau. Le second est l'impossibilité d'adapter le débit physique suivant l'état du support de transmission, donc les paquets sont transmis à un débit physique fixe. Le troisième est l'impossibilité de retransmettre au niveau de la couche MAC les paquets perdus.

Une nouvelle approche a récemment été proposée pour remédier à ses problèmes. Elle consiste en l'élection d'un récepteur appelé leader pour assurer l'acquittement des paquets reçus. Ainsi, l'émetteur peut adapter le débit physique et retransmettre les paquets perdus.

Nous allons dans ce projet montrer l'apport de cette nouvelle approche par rapport à la méthode de transmission multipoint standard à l'aide de la simulation. Nos simulations seront effectuées à l'aide du simulateur OMNET++.

Sujet traité :

Ce projet consiste à intégrer de nouvelles fonctionnalités dans le simulateur OMNET++ (implémenter de nouveaux protocoles, ajouter de nouveaux modules, etc.. ) afin de permettre des simulations plus réalistes. De plus, il s'agit d'implémenter de nouveaux algorithmes d'élection et d'adaptation de débit physique pour la transmission vidéo en ajoutant de nouvelles trames de gestion du réseau. Ces trames serviront à estimer l'état actuelle du réseau (débit, SNR, Perte de paquet, etc..). Enfin, Il s'agit de simuler quelques exemples de scénarios de transmission multipoint.

Dans ce rapport, nous proposons un cadre théorique pour la transmission vidéo dans les réseaux IEEE 802.11. En premier lieu, nous allons introduire le cadre général de notre projet, ensuite nous allons traiter la transmission vidéo dans les réseaux IEEE 802.11. En effet, dans un premier chapitre, nous étudierons l'existant. Nous y présenterons d'abord les modèles physiques de propagation, la norme IEEE 802.11, les protocoles de temps réel ainsi que les différentes approches proposées pour la diffusion multipoint. Dans un deuxième chapitre, nous spécifierons les besoins fonctionnels et les contraintes de notre application. Dans un quatrième chapitre, nous entamerons la conception avec une description des nouveaux

modules ajoutés. Enfin, un cinquième chapitre s'intéressera à la réalisation dans lequel nous montrerons les résultats de nos simulations.

Présentation de l'organisme d'accueil

Dans cette première partie, il s'agit de mettre le stage dans son cadre général. Nous nous proposons alors de présenter l'environnement du stage à travers une présentation de l'équipe PLANETE INRIA- Sophia Antipolis qui a proposé ce sujet.

1. INRIA

L'INRIA, Institut National de Recherche en Informatique et Automatique (FRANCE) placé sous la double tutelle des ministères français de la recherche et de l'industrie, a pour vocation d'entreprendre des recherches fondamentales et appliquées dans les domaines des sciences et technologies de l'information et de la communication (STIC). L'institut assure également un fort transfert technologique en accordant une grande attention à la formation par la recherche, à la diffusion de l'information scientifique et technique, à la valorisation, à l'expertise et à la participation à des programmes internationaux. L'INRIA accueille dans ses 6 unités de recherche situées à Rocquencourt, Rennes, Sophia Antipolis, Grenoble, Nancy et Bordeaux, Lille, Saclay et sur d'autres sites à Paris, Marseille, Lyon et Metz, 3600 personnes dont 2800 scientifiques qui travaillent dans plus de 138 projets de recherches communs.

2. L'unité de Recherche INRIA Sophia Antipolis

Créée au coeur de la technopole Sophia Antipolis en 1983, l'unité de recherche regroupe, sur ses sites de Sophia Antipolis, Marseille et Montpellier, 500 personnes dont 380 scientifiques réparties au sein d'une trentaine d'équipes en partenariat avec le CNRS, plusieurs universités et grandes écoles. Leurs travaux portent sur la conception et la programmation de systèmes informatiques performants, la représentation et la manipulation d'informations complexes, la création, la modélisation et la simulation d'expériences complexes. Ils permettent l'avancée des connaissances dans quatre grands domaines :

- réseaux et systèmes

- génie logiciel et calcul symbolique

- interaction homme machine

- images, données, connaissances, simulation et optimisation des systèmes complexes.

3. Le projet Planète

Notre stage est effectué au sein de l'équipe PLANETE. Les activités de cette équipe, localisés à l'INRIA Sophia Antipolis et à l'INRIA Rhône-alpes, sont centrées sur la conception, la mise en oeuvre et l'évaluation des protocoles et des applications Internet. Leur travaux s'articulent autour plusieurs axes dont l'étude de l'impact des nouveaux supports de transmission sur les protocoles; le passage à l'échelle du routage multipoint; le support de la qualité de service dans l'Internet; et les applications interactives multi-utilisateurs.

Chapitre 1 : Etat de l'art

Introduction

Notre travail consiste à mettre en évidence les avantages des nouvelles approches proposées pour améliorer la qualité de transmission multimédia dans les réseaux IEEE 802.11. Pour ce faire, nous avons recourt à la simulation qui sera réalisée grâce au simulateur OMNET++ [Omnet, 07]. Ce dernier pose de diverses contraintes comme le besoin de modèles physique de propagation réalistes, la manque de la couche physique IEEE 802.1 1a et l'absence de protocoles temps réels RTP et RTCP. Dans ce premier chapitre nous allons essentiellement introduire la norme IEEE 802.11 en détaillant les deux couches physique et çiiliaisons de donnée. Nous présentons dans cette première partie quelques modèles de transmission physique ainsi que les algorithmes d'adaptation du débit physique au niveau liaison de donnée. Nous introduisons ensuite le standard RTP avec ses deux protocoles RTP et RTCP. Puis, nous présentons un état de l'art sur la transmission multipoint dans les réseaux IEEE 802.11 avec une présentation des nouvelles approches adoptées pour améliorer la qualité de la transmission vidéo. Enfin, nous présentons une vue d'ensemble du simulateur OMNET++.

1. Introduction à la norme IEEE 802.11

La norme IEEE 802.11 (ISO/IEC 8802-11) est un standard international décrivant les caractéristiques d'un réseau local sans fil Wireless Local Area Network (WLAN). Grâce au IEEE 802.11, il est possible de créer des réseaux locaux sans fils à haut débit à condition que l'ordinateur à connecter ne soit pas trop distante par rapport au point d'accès. Dans la pratique, ce réseau permet de relier des ordinateurs portables, des ordinateurs de bureau, des assistants personnels (PDA) ou tout type de périphérique à une liaison haut débit sur un rayon de plusieurs dizaines de mètres en intérieur, et à plusieurs centaines de mètres en environnement ouvert. Ainsi, des opérateurs commencent à irriguer des zones à fortes concentration d'utilisateurs (gares, aéroports, hotels, trains, ...) avec des réseaux sans fils. Ces zones d'accès sont appelées « hot spots ». Nous présentons dans ce qui suit les deux couches de la norme IEEE 802.11 qui sont la couche physique et la couche liaison de donnée.

1.1. La couche PHY IEEE 802.11

Le rôle de la couche physique Physical Layer (PHY) est de transporter correctement les données que l'émetteur souhaite envoyer au récepteur. Elle est divisée en deux sous- couches, PLCP Physical Layer Convergence Protocol et PMD Physical Medium Dependent. Cette dernière s'occupe de l'encodage des données, alors que la sous couche PLCP prend en charge l'écoute du support, en fournissant à cette occasion un signal à la couche MAC pour lui dire si le support est libre ou non.

La couche PHY définit aussi la modulation des ondes radioélectriques et les caractéristiques de la signalisation pour la transmission de données. La norme 802.11 propose en réalité trois couches physiques, définissant des modes de transmission alternatifs comme le montre le tableau 1.1

La couche IEEE 802.1 1b utilise la bande 2.4 Ghz et permet d'atteindre un débit théorique de 11 Mbps en utilisant les technologies d'étalement de spectre avec sauts de fréquence frequency hopping spread spectrum (FHSS), de séquence directe direct sequence spread spectrum (DSSS), et l'infra rouge (IR). Alors que IEEE 802.1 1a transmet dans la bande 5 GHz et peut atteindre un débit de 54Mbps en utilisant orthogonal frequency division multiplexing (OFDM). Le standard IEEE 802.11 g est une extension du IEEE 802.1 1b qui peut atteindre un débit théorique maximale de 54 Mbps.

Chaque mode de transmission est caractérisé par ses méthodes de modulation. La performance d'une modulation par rapport à une autre réside dans sa résistance contre les erreurs de propagation, les interférences et le fading.

Pour chaque mode de transmission, il y a toujours un mode de transmission de base utilisé généralement pour la transmission des ACK, RTS, CTS et les entêtes PLCP. Ce mode de transmission utilise BPSK ou DBPSK comme modulation pour avoir le minimum d'erreur. Les modes de transmission de base pour les couches physiques sont décrits dans le tableau 1.1. Par exemple, le débit de base pour IEEE 802.1 1b est 1 Mbps.

Tableau 1.1 Caractéristiques des différentes couches physiques IEEE 802.11 [Manshaei,
05]

Dans la norme IEEE 802.11, chaque paquet peut être envoyé avec deux débits différents. L'entête PLCP est envoyée avec le débit de base, alors que la deuxième partie du paquet est envoyée avec un débit généralement plus élevé. Le débit de la deuxième partie est indiqué dans un champs de l'entête PLCP. Par la suite, le récepteur décode l'entête PLCP afin de connaître le débit de la deuxième partie du paquet.

1.2. Les différents modèles de propagation

Les ondes électromagnétiques sont actuellement le support de la plupart des communications sans fil et l'étude de leur propagation devient de plus en plus importante afin de pouvoir prédire l'onde reçue par une station réceptrice, connaissant l'onde émise. Elles sont utilisées pour diverses applications, à l'intérieur ou à l'extérieur, mais l'influence des effets qu'elles doivent subir est bien souvent différent selon le contexte. En effet, des phénomènes tels que la diffraction, la dispersion, la réflexion, l'absorption ou encore la transmission ont un impact direct sur la propagation du signal.

La modélisation de la propagation dans un réseau IEEE 802.11 comprend les modèles d'affaiblissement du signal à grande échelle large-scale path loss et les modèles à petite échelle small-scale path loss ainsi que les différentes fonctions de calcul de la puissance reçue et les méthodes de calcul du taux d'erreur d'un bit Bit Error Rate (BER) et du taux d'erreur d'un paquet Packet Error Rate (PER).

1.2.1. Les modèles à grande échelle

1.2.1.1. Le modèle Free-Space

Free-Space est le modèle le plus utilisé dans la majorité des simulateurs afin de calculer la puissance reçue. Ce modèle exige l'existence d'un chemin direct entre l'émetteur et le récepteur. De plus, Il exige que les deux noeuds se trouvent dans un environnement sans bruit.

La formule (1.1) de Friis est utilisée pour le calcul de la puissance reçue [Rappaport,

02].

Avec

Pr : la puissance reçue par le récepteur

Pt : la puissance transmise par l'émetteur

Gt : le gain de l'émetteur

Gr : le gain du récepteur

ë : la longueur l'onde

d : la distance entre le récepteur et l'émetteur

L : la perte due au système

1.2.1.2. Le modèle Two-Ray

Ce modèle est plus réaliste que le premier puisqu'il tient en compte des réflexions subites par le signal lors de sa propagation de l'émetteur jusqu'à son arrivée au récepteur. L'émetteur et le récepteur se trouvent dans un environnement sans bruit avec un chemin direct entre eux. Par suite, Le signal émis par l'émetteur subira des réflexions afin d'arriver au récepteur. Ce modèle sera le bon choix surtout lorsque la distance entre l'émetteur et le récepteur est assez grande et que l'émetteur se trouve à une grande hauteur.

A une grande distance de l'émetteur, la distance d est suffisamment grande devant (ht*hr) ² et donc, la puissance reçue est calculée grâce la formule (1.2) [Rappaport, 02] :

Avec

Pr : la puissance reçue par le récepteur

Pt : la puissance transmise par l'émetteur

Gt : le gain de l'émetteur

Gr : le gain du récepteur

ht : la hauteur de l'émetteur

hr : la hauteur du récepteur

d : la distance entre le récepteur et l'émetteur

L : la perte due au système

1.2.1.3. Le modèle Shadowing

Ce modèle n'exige pas l'existence d'un chemin direct entre l'émetteur et le récepteur. Il modélise les déviations subites par le signal lors de sa propagation. En adoptant ce modèle, nous tenons en compte des phénomènes imprévisibles que peut subir le signal. La puissance reçue dans ce modèle varie en fonction du logarithme de la distance. La perte moyenne pour une distance donnée est exprimée par PathLossExponent. Nous ajoutons ensuite le phénomène de Shadowing qui est une variation statistique du signal autour de la valeur calculé à l'aide de Free-Space théorique. Cette variation est de moyenne nulle et sa variance ó est bien évidemment non nulle.

Pour calculer la puissance reçue, nous calculons tout d'abord une puissance référence en supposant que le récepteur est à une distance, dans notre cas 1 mètre, de la source à l'aide

de la formule de Friis. Ensuite, nous ajoutons la perte due à la distance et l'effet de Shadowing.

Les valeurs de PathLossExponent et Shadowing dépendent de l'environnement. Le tableau 1.2 présente les valeurs des environnements typiques selon [Khosroshahy, 06] et [Rappaport, 02].

Tableau 1.2 Les valeurs typiques de Path loss Exponent et Shadowing Variance
[Khosroshahy, 06]

1.2.2. Les modèles à petite échelle « fading »

Small-Scale fading, ou simplement fading, est utilisé selon T. Rappaport [Rappaport, 02] pour décrire une fluctuation rapide de l'amplitude ou de la phase du signal pendant une très courte période. La cause de ce phénomène est l'interférence entre les différentes versions du signal émis quand elles arrivent au récepteur dans des instants distincts.

Ce modèle peut être ajouté avec l'un des modèles à grande échelle déjà cité. Il s'intéresse au coté dynamique de l'environnement, comme les mouvements de l'émetteur ou du récepteur au cours des transmission des données.

1.2.3. Calcul de la probabilité d'erreur de bit BER Bit Error Rate

Pour obtenir des simulations de réseaux sans fils IEEE 802.11 plus réalistes, il faut pouvoir estimer avec précision les valeurs du BER et PER. Dans notre projet, nous sommes basés sur le travail de Masood Khosroshahy [Khosroshahy, 06] pour le calcul du BER et du PER. Il a déjà intégré son travail dans le simulateur YANS. Les formules pour le calcul du BER pour les différents types de modulations sont bien détaillées dans [Khosroshahy, 06].

1.2.4. Calcul de la probabilité d'erreur de paquet PER Packet Error Rate

Dans cette partie, nous introduisons deux méthodes de calcul de la probabilité qu'un paquet soit perdu. La première, qui est la plus simple, est appelée la distribution uniforme de l'erreur Uniform Error Distribution. La deuxième est une nouvelle méthode proposée par Ramin Khalili et Kavé Salamatian [Khalili et al., 06].

1.2.4.1. Distribution uniforme de l'erreur

des débits de transmission différents. La probabilité de succès d'une transmission d'un morceau Chunk Success Rate (CSR) est calculée en fonction du BER de chaque bit de ce morceau à l'aide de l'équation (1.4).

Ensuite, La probabilité de succès d'une transmission d'un paquet PSR sera le produit des deux probabilités de chaque morceau [Manshaei et al. 05]. Enfin, la probabilité d'erreur d'un paquet PER sera 1 -PSR.

Cette méthode suppose que la valeur de BER est uniforme pour tous les bits d'un

paquet.

1.2.4.2. Distribution d'erreur non uniforme

Dans ce paragraphe, nous présentons une deuxième approche pour le calcul du BER et du PER en se basant sur [Khalili et al., 06]. Selon Khalili et Salamatian [Khalili et al., 06] l'hypothèse que la distribution d'erreur est uniforme mène à une surestimation de la valeur PER. Ils ont ajouté de nouvelles notions afin de proposer d'autres formules pour le calcul du PER comme EER et ë. Le taux d'erreur Error Event Rate (EER) est une probabilité indiquant la fréquence d'occurrence d'une erreur dans une partie d'un paquet. ë est le paramètre d'une loi géométrique qui décrit la longueur d'une période d'erreur. Ce taux dépend de la valeur de SNR et aussi du FEC. En bref, pour un morceau de paquet, il s'agit de tirer un nombre aléatoire qui serait l'événement d'un début d'une période d'erreur. Ensuite, tirer un autre nombre aléatoire qui représentera la durée en bits de cette erreur. Enfin, pour chaque bit dans cette période nous choisissons un nombre aléatoire et le comparons avec BER/ ë.

1.3. La couche MAC 802.11

La couche de liaison de données de 802.11 se compose de deux sous-couches : le contrôle de la liaison logique Logical Link Control (LLC) et le contrôle d'accès au support Medium Access Control (MAC). Le standard 802.11 utilise la norme LLC 802.2 et un adressage sur 48 bits, tout comme les réseaux IEEE 802, simplifiant ainsi le pontage entre les réseaux sans fil et filaires. Le contrôle d'accès au support est en revanche propre aux WLAN. La couche MAC 802.11 est très proche de 802.3 dans sa conception : il est conçu pour supporter de multiples utilisateurs sur un support partagé en faisant détecter le support par l'expéditeur avant d'y accéder.

Pour les LAN Ethernet IEEE 802.3, le protocole CSMA/CD Carrier Sense Multiple Access with Collision Detection régule l'accès des stations Ethernet au câble. Dans un WLAN 802.11, la détection des collisions est impossible du fait de ce qu'on appelle le problème «near/far». Pour détecter une collision, une station doit être capable de transmettre et d'écouter en même temps. Or, dans les systèmes radio, il ne peut y avoir transmission et écoute simultanées. En plus, la collision se fait au voisinage du récepteur et non pas de l'émetteur. Donc, l'émetteur peut ne pas détecter la collision.

Pour prendre en compte cette différence, le standard 802.11 fait appel à un protocole légèrement modifié, baptisé CSMA/CA Carrier Sense Multiple Access with Collision Avoidance, ou à la fonction DCF Distributed Coordination Function. Le protocole

CSMA/CA tente d'éviter les collisions en imposant un accusé de réception systématique des paquets (ACK), ce qui signifie que pour chaque paquet de données arrivé intact, un paquet ACK est émis par la station de réception.

Ce protocole CSMA/CA fonctionne de la manière suivante [Ergen, 02] : une station qui souhaite émettre commence par explorer les ondes et, si aucune activité n'est détectée, elle attend un temps aléatoire avant de transmettre si le support est toujours libre. Si le paquet est intact à la réception, la station réceptrice émet une trame ACK qui, une fois reçue par l'émetteur, met un terme au processus. Si la trame ACK n'est pas détectée par la station émettrice (parce que le paquet original ou le paquet ACK n'a pas été reçu intact), une collision est supposée et le paquet de données est retransmis après attente d'un nouveau temps aléatoire.

Figure 1.1 Le fonctionnement de CSMA/CA avec RTS/CTS [Van Steyvoort, 06]

CSMA/CA permet donc de partager l'accès aux ondes. Ce mécanisme d'accusé de réception explicite gère aussi très efficacement les interférences et autres problèmes radio.

Autre problème de la couche MAC, spécifique au sans fil, celui du «noeud caché», où deux stations situées de chaque côté d'un point d'accès peuvent entendre toutes les deux une activité du point d'accès, mais pas de l'autre station, problème généralement lié aux distances ou à la présence d'un obstacle. Pour résoudre ce problème, le standard 802.11 définit sur la couche MAC un protocole optionnel de type RTS/CTS Request to Send/Clear to Send. Lorsque cette fonction est utilisée, une station émettrice transmet un RTS et attend que le point d'accès réponde par un CTS. Toutes les stations du réseau peuvent entendre le point d'accès, aussi le CTS leur permet de retarder toute transmission prévue, la station émettrice pouvant alors transmettre et recevoir son accusé de réception sans aucun risque de collision. Du fait que le protocole RTS/CTS ajoute à la charge du réseau comme le montre la figure 1.1 en réservant temporairement le support, il est généralement réservé aux plus gros paquets, dont la retransmission s'avérerait lourde du point de vue de la bande passante.

1.3.1. Les modes opératoires de IEEE 802.11

Le standard 802.11 concerne deux types d'équipements, une station sans fil, en général un PC équipé d'une carte réseau sans fil, et un point d'accès (AP), qui joue le rôle de pont entre le réseau filaire et le réseau sans fil. Ce point d'accès se compose habituellement d'un émetteur/récepteur radio, d'une carte réseau filaire comme par exemple IEEE 802.3 et d'un logiciel de pontage conforme au standard 802.1d. Le point d'accès se comporte comme la station de base du réseau sans fil, agrégeant l'accès de multiples stations sans fil sur le réseau filaire.

Le standard 802.11 définit deux modes : un mode infrastructure et un mode ad hoc. 1.3.1.1. Le mode infrastructure

Le réseau sans fil consiste au minimum en un point d'accès connecté à l'infrastructure du réseau filaire et un ensemble de postes réseaux sans fil. Cette configuration est baptisée Basic Service Set (BSS). Un Extended Service Set (ESS) est un ensemble d'au moins deux BSS formant un seul sous-réseau. En entreprise, la plupart des WLAN devront pouvoir accéder aux services pris en charge par le LAN filaire (serveurs de fichiers, imprimantes, accès Internet).

1.3.1.2. Le mode ad hoc

Le mode ad hoc Independent Basic Service Set (IBSS) représente simplement un ensemble de stations sans fil 802.11 qui communiquent directement entre elles sans point d'accès. Ce mode permet de créer rapidement et simplement un réseau sans fil là où il n'existe pas d'infrastructure filaire.

1.3.2. Les algorithmes d'adaptation du débit physique

La transmission des ondes est susceptible à beaucoup de phénomènes physiques que nous avons listé dans la section 1.2. Cependant, les variations de ses conditions de transmission peuvent être classé en deux catégories selon leur durée : l'une qui soit rapide comme la fermeture d'un porte, ou le déplacement d'un grand objet, et l'autre qui dure dans le temps comme se déplacer d'une chambre vers une autre. Ces perturbations auront toujours un effet sur l'énergie du signal radio, et dans la majorité des cas elles augmentent le BER

Dans cette partie, nous présentons quelques algorithmes d'adaptation du débit de transmission physique en fonction des conditions du canal.

1.3.2.1. Le protocole Auto Rate Feedback (ARF)

ARF [Kamerman et al., 97] Auto Rate Feedback, est l'un des premiers algorithmes publiés. Chaque station essaie d'augmenter son débit de transmission physique après un certain nombre de transmissions avec succès et de diminuer ce débit en cas d'un ou deux échecs successifs. Plus spécifiquement, ARF augmente le débit de transmission après dix transmissions successives avec succès et il le diminue lors de deux échecs successifs ou bien lors du premier échec juste après une augmentation du débit physique.

1.3.2.2. Le protocole Receiver Based Auto Rate (RBAR)

RBAR [Holland et al., 01] Receiver Based Auto Rate a pour but d'optimiser le débit au niveau application. Cet algorithme exige l'échange des trames RTS/CTS entre la station émettrice et la station réceptrice. Cette dernière calcule le débit de transmission des données à l'aide du débit avec lequel a été envoyée la trame RTS et aussi à l'aide des valeurs de SNR des trames de données déjà reçus. Le débit de transmission PHY de la prochaine trame de donnée est envoyé avec la trame CTS. La figure 1.2 montre la performance de RBAR en le comparant avec ARF.

L'inconvénient de RBAR est qu'il exige que les toutes les stations écoutent les trames RTS et CTS afin de mettre à jour leur Network Allocation Vector (NAV) et aussi des modifications dans l'entête MAC IEEE 802.11.

Figure 1.2 Le débit de transmission physique RBAR et ARF [Holland et al., 01] 1.3.2.3. Le protocole Adaptative Auto Rate Feedback (AARF)

AARF [Lacage et al., 04] Adaptative Auto Rate Feedback est une amélioration de l'algorithme ARF. Ce dernier est la bonne solution pour un environnement où il y'a beaucoup de mouvement. Mais, pour un environnement stable, le protocole ARF essaye périodiquement d'augmenter le débit alors que le débit de transmission actuel est le meilleur. AARF introduit de nouvelles variables pour minimiser le nombre de d'échecs suite à une augmentation du débit physique. AARF propose de doubler le nombre de transmissions avec succès nécessaire pour augmenter le débit de transmission physique lors d'un échec suite à une augmentation du débit. La figure 1.3 compare l'évolution du débit de transmission physique de deux stations utilisant les deux algorithmes ARF et AARF. Nous constatons que AARF minimise le nombre de pertes liées à une augmentation du débit.

Figure 1.3 Comparaison entre les deux approches ARF et AARF [Manshaei, 05]

La figure 1.4 représente la courbe débit en fonction de la distance, résultat des simulations réalisées au sein de l'équipe PLANETE à l'aide du simulateur NS-2. Elle montre l'apport de l'algorithme AARF par rapport aux autres algorithmes déjà cités.

Figure 1.4 Le débit moyen avec les trois différents algorithmes [Manshaei, 05]

2. La transmission video dans les réseaux IEEE 802.11

La deuxième partie de ce chapitre est consacrée à l'étude de la transmission vidéo dans les réseaux IEEE 802.11. Nous commençons par la présentation du protocole RTP puis nous décrivons le protocole RTCP. Ensuite, nous présenterons l'état de l'art de la transmission multipoint dans les réseaux IEEE 802.11.

2.1. Les protocoles temps réels

Les applications temps réel sont soumises à des contraintes de temps strictes qui rendent impossible l'utilisation de Transport Control Protocol (TCP). Le protocole Real-time Transport Protocol [Schulzrinne, et al., 03] (RTP) essaye de palier aux inconvénients des protocoles TCP et User Datagram Protocol (UDP). En effet, les mécanismes du protocole TCP, tels que la fiabilité par acquittement et retransmission des paquets manquants, le contrôle de flux par la fenêtre de congestion (slow start), sont incompatibles avec les applications temps réel. En plus les paquets UDP se trouvent dépourvus de certaines informations comme le numéro de séquence.

2.1.1. Le protocole Real-time Transport Protocole (RTP)

Le protocole RTP [Schulzrinne, et al., 03] assure une numérotation et un horodatage des paquets en encapsulant les données dans une nouvelle entête.

Il repose lui-même sur le protocole UDP, qui ne renvoie pas les trames perdues en cours de route, afin de privilégier l'enchaînement du son et des images, plutôt que l'intégrité des données. La qualité peut en souffrir si la liaison est mauvaise, mais c'est un mal nécessaire à la diffusion en direct. Dans le cadre même de notre projet, deux possibilités se présentent. La première consiste à envoyer simultanément un flux de données vers chacun des clients. L'autre solution est le multipoint qui se caractérise par la diffusion d'un flux unique vers un groupe multipoint, dont les clients lisent simultanément les mêmes informations. Dans l'objectif d'avoir une optimisation de la consommation de la bande passante, il est préférable d'utiliser une diffusion en multipoint. Le protocole RTP va ainsi pouvoir assurer les fonctionnalités suivantes :

· reconstituer la base de temps des flux temps réel,

· détecter les pertes de paquets et en informer la source.

Mais le protocole RTP ne permet pas de réserver les ressources dans le réseau, d'assurer une fiabilité et de garantir le délai de livraison.

2.1.2. Le protocole Real-time Transport Controle Protocole (RTCP)

Le protocole RTP est complété par le protocole RTCP qui transmet périodiquement des paquets de contrôle à tous les participants d'une session. Il adopte le même mécanisme de transmission que le protocole RTP.

2.1.2.1. Les fonctions de RTCP

Selon [Mélin, 01] et [Perkins, 03], le protocole RTCP remplit trois fonctions principales plus une optionnelle. Il retourne les statistiques feedback sur la qualité de réception des données transmises dans les paquets RTP. Ces informations temps réel peuvent

être exploitées par la source pour adapter le type de codage au niveau des ressources disponibles. RTCP transporte un identificateur unique de la source RTP, appelé Nom Permanent Canonical NAME (CNAME) car l'identifiant SSRC peut changer et ne permet pas, à lui tout seul, d'identifier une source. Les destinataires peuvent avoir besoin du nom permanent, CNAME, pour associer plusieurs flux de données d'un même participant dans un ensemble de sessions RTP, par exemple pour une synchronisation audio-vidéo.

De plus, la réception des feedbacks et la connaissance du CNAME supposent que tous les participants envoient des paquets RTCP régulièrement. Ces informations servent à ajuster le débit de sortie et à l'adapter de manière à accommoder toutes les personnes désirant se joindre à l'évènement.

Enfin, la quatrième fonction qui est optionnelle, consiste à transmettre des informations permettant une régulation minimale des membres. RTCP assure l'identification des participants à une conférence en jouant le rôle d'un canal de liaison entre des participants fluctuants, et a priori non identifiés.

2.1.2.2. Les paquets RTCP

Plusieurs types de paquets sont définis, de manière à transporter une grande variété d'informations de contrôle (voir annexe A):

· Rapport d'émetteur (SR) : ce paquet regroupe un ensemble de statistiques de transmission et de réception en provenance des participants qui sont des émetteurs actifs.

· Rapport de récepteur (RR) : c'est un paquet regroupant un ensemble de statistiques en provenance de participants qui sont des récepteurs.

· Description de source (SDES) : les paquets de description de source comprennent plusieurs éléments, dont le CNAME. Ils établissent une véritable carte de visite de la source.

· BYE : c'est un paquet qui indique le départ d'un participant de la session.

· APP: c'est un paquet qui permet d'ajouter des fonctions spécifiques à l'application.

Chaque paquet RTCP commence par une partie fixe, semblable à celle du paquet de données RTP, suivie par des éléments structurés, de taille variable, selon le type du paquet, mais qui se concluent toujours par une terminaison de 32 bits. Plusieurs paquets RTCP peuvent être concaténés, sans adjonction de séparateurs, pour former un paquet RTCP composite.

Ces paquets RTCP doivent respecter et tenir compte d'un certain nombre de paramètres essentiels pour assurer le bon déroulement de la session RTP. Parmi ces paramètres :

- La fréquence de transmission des paquets RTCP : lors d'une conférence de plusieurs centaines de membres, les flux RTP sont par nature autolimitatifs car une ou deux personnes seulement parlent en même temps. En revanche, le flot de contrôle ne s'autolimite pas, bien au contraire. Si les rapports de réception de chaque participant sont toujours envoyés selon la même périodicité, le trafic de contrôle va croître de façon linéaire avec le nombre de participants. Il convient donc de limiter cette fréquence en réduisant le trafic de contrôle à une

fraction minime et connue de la bande passante. A cet effet, il est suggéré de n'allouer à RTCP que 5% au plus de la bande passante globale de la session.

- La mise à jour du nombre de participants : Le calcul de l'intervalle entre les rapports RTCP dépend d'une estimation du nombre de sites participant à la session. Les nouveaux membres sont ajoutés dès leur détection, dans une base indexée par l'identificateur SSRC ou CSRC de leurs en-têtes RTP. Un membre peut être supprimé de la liste quand le paquet RTCP BYE, avec l'identifiant correspondant, est reçu.

- Allocation de bande passante pour la description de source SDES : Plusieurs types de description de sources (SDES) sont prévus, en plus des mentions obligatoires contenues dans le nom permanent CNAME, tels que NAME (nom de la personne) et EMAIL (adresse email). Les descriptions de sources SDES permettent également de définir des types de paquets RTCP spécifiques à une application. Les applications doivent prendre des précautions, en allouant de la bande passante de contrôle à ces informations additionnelles. Elles peuvent ralentir la vitesse d'émission des rapports de réception et des CNAME, diminuant ainsi les performances du protocole. Il est recommandé de limiter à 20% la part de la bande passante de contrôle consacrée au transport des informations complémentaires SDES.

2.2. La transmission multipoint sur IEEE 802.11

La transmission multipoint est une technique qui nous permet de gagner de façon remarquable dans les transmissions multimédia surtout que les besoins des nouvelles applications augmentent avec l'apparition du WiMAX.

Pourtant, le standard IEEE 802.11 ne supporte pas de mécanismes spécifiques pour la transmission multipoint. Cette transmission se fait de la même manière que dans la diffusion. L'utilisation du standard pose trois problèmes principaux qui sont:

Le contrôle de congestion : Sans avoir un mécanisme de feedback, le contrôle de congestion est impossible pour les flux multipoint surtout que ce flux sera en concurrence avec d'autres flux point à point. En plus, en cas de collision dans les réseaux IEEE 802.11, on double la taille de la fenêtre de contention. Donc, sans un mécanisme de contrôle de congestion, on ne peut pas adapter le débit de transmission.

La fiabilité de transmission : La plupart des applications multimédia tolèrent la perte des paquets dans le réseau, mais en cas de grande perte de paquets la qualité de transmission se détériorera rapidement.

L'adaptation du débit physique de transmission : Pour optimiser la qualité de transmission d'un flux multimédia, les réseaux IEEE 802.11 doivent adapter dynamiquement leur débit physique de transmission. Un grand nombre de mécanismes ont été proposés comme RBAR, ARF et AARF. Mais ces mécanismes ne sont pas adoptés pour la transmission multipoint. En général, les points d`accès utilisent des débits fixes pour la transmission multipoint.

2.2.1. Le protocole LEP (Leader Election Protocol)

La solution la plus adéquate pour la résolution des trois problèmes identifiés dans la transmission multicast avec la norme 802.11 est de la faire de la même manière que la transmission unicast avec l'utilisation d'une approche basée sur le Leader, c'est-à-dire qu'une station parmi les récepteurs prend la responsabilité d'acquitter les trames multipoint. Les trames de contrôle serviront comme déclencher d'une retransmission possible, d'une

adaptation de la fenêtre de contention ou bien pour d'une sélection du débit de transmission physique.

Le protocole Leader Election Protocol (LEP) [Seok et al., 06], celui le plus récent, sélectionne dynamiquement la station qui a la plus mauvaise condition comme Leader. Le mécanisme LEP est basé sur les paquets IGMP.

2.2.2. Le protocole LB-ARF (Leader Based-ARF)

Nous décrivons un nouveau mécanisme pour adapter le débit de transmission physique des flux multipoint, appelé LB-ARF. Il est le modèle le plus simple, basé sur le mécanisme de Leader. Donc, le Leader, élu grâce à LEP, acquitte les trames reçues du AP. Ce dernier contrôle le débit physique de la même manière que ARF.

Quand le temporisateur expire ou bien la réception de dix acquittements consécutifs alors le débit de transmission passe au prochain niveau. Dans le cas contraire, on cas de perte de 2 trames successives, le débit de transmission physique diminue, c'est-à-dire le débit descend vers le niveau le plus bas, et le temporisateur se initialisera à 0.

Cependant, LB-ARF n'est pas apprécié dans les environnements mobiles tels que les réseaux Ad-hoc car les positions des stations varient de façon rapide.

2.2.3. Le protocole LBMS (Leader Based Multicast Services)

Le protocole LBMS [Seok , 07] est une nouvelle approche basée aussi sur le mécanisme Leader. Il ajoute à LB-ARF de nouvelles trames de contrôle de congestion dans le réseau qui sont : LBMS request, LBMS report. Le Point d'accès sélectionne un Leader pour chaque flux multicast. Cette élection se base sur les rapports envoyés périodiquement par les stations qui peuvent contenir des informations sur la qualité de réception comme PER, SNR etc.

La trame LMBS request est envoyée par une station vers AP auquel elle est associée pour s'abonner à un ou plusieurs groupes multipoint.

La trame LBMS report est une nouvelle trame envoyée par une station vers le AP de façon périodique. Elle contiendra des statistiques sur sa performance tels que Packet Loss Rate, SNIR.

Les trames LBMS sont envoyées par le AP vers une station et vice versa.

3. Le simulateur OMNET ++

Dans ce projet, nous allons réaliser nos expérimentations à l'aide de OMNET++ [Omnet, 07] qui est un simulateur à évènements discrets orienté objet, basé sur C++. Il a été conçu pour simuler les systèmes réseaux de communication, les systèmes multi processeurs, et d'autres systèmes distribués. OMNET++ [Omnet, 07] est un projet open source dont le développement a commencé en 1992 par Andras Vargas à l'université de Budapest. Actuellement, Ce simulateur est utilisé par des dizaines d'université pour la validation de nouveaux matériels et logiciels, ainsi que pour l'analyse de performance et l'évaluation de protocoles de communication.

L'avantage de OMNET ++ est sa facilité d'apprentissage, d'intégration de nouveaux modules et la modification de ceux déjà implémentés. Nous introduisons dans la suite l'architecture du simulateur OMNET++ et les librairies Mobility Framework [MF, 07] et INET [INET, 07].

3.1. Architecture de OMNET++

L'architecture de OMNET++ est hiérarchique composé de modules. Un module peut être soit module simple ou bien un module composé. Les feuilles de cette architecture sont les modules simples qui représentent les classes C++. Pour chaque module simple correspond un fichier .cc et un fichier .h. Un module composé est composé de simples modules ou d'autres modules composés connectés entre eux. Les paramètres, les sous modules et les ports de chaque module sont spécifiés dans un fichier .ned.

La communication entre les différents modules se fait à travers les échanges de messages. Les messages peuvent représenter des paquets, des trames d'un réseau informatique, des clients dans une file d'attente ou bien d'autres types d'entités en attente d'un service. Les messages sont envoyés et reçus à travers des ports qui représentent les interfaces d'entrer et de sortie pour chaque module.

La conception d'un réseau se fait dans un fichier .ned et les différents paramètres de chaque modules sont spécifies dans un fichier .ini. OMNET++ génère à la fin de chaque simulation deux nouveaux fichiers omnet.vec et omnet.sca qui permettent de tracer les courbes et calculer des statistiques.

3.2. La librairie MF

La librairie MF est une extension du simulateur OMNET++. Elle a été développée par une équipe de chercheurs à l'université de Berlin. Ca dernière version a été proposée par Marc Loebbers en Octobre 2003. Elle est un bon support pour la simulation des réseaux sans infrastructure et mobile. Elle peut être utilisée pour la simulation de :

· réseaux sans fils,

· réseaux mobiles,

· réseaux Ad-hoc.

3.3. La librairie INET

INET est une librairie open source pour la simulation des réseaux informatiques dans l'environnement OMNET++. Elle contient des modules pour plusieurs protocoles comme TCP, IP, UDP, Ethernet, PPP, IEEE 802.11, MPLS, RSVP et beaucoup d'autres protocoles.

Dans ce paragraphe, nous allons présenter une étude de l'existant de la librairie INET. Nous allons décrire plus précisément l'implémentation des couches PHY, MAC, IP et RTP dans INET.

3.3.1. La couche PHY

Andras Varga s'est basée par l'implémentation de la couche PHY faite dans MF par Marc Löebbers [Löbbers et al., 07]. Dans la librairie INET, version Octobre 2006, seulement la couche physique IEEE 802.1 1b est implémentée. Le calcul au niveau PHY de la puissance reçue se fait à l'aide de la formule de Friis, c'est-à-dire que seul le modèle Free-Space est implémenté comme modèle de propagation.

3.3.2. La couche MAC

La couche MAC IEEE 802.1 1b est implémentée dans la librairie INET, elle supporte le mécanisme RTS/CTS. Il n'y a que l'algorithme DCF implémenté, le PCF n'est pas implémenté. Le débit de transmission physique est constant pendant la simulation. Aucun des algorithmes d'adaptation du débit de transmission physique n'est implémenté. Les paquets multipoints au niveau MAC sont envoyés de la même manière que les paquets broadcast. Le filtrage de ces paquets se fait au niveau IP.

3.3.3. La couche IP

Le routage multipoint au niveau IP est déjà implémenté mais de manière statique. C'est à dire que l'utilisateur doit configurer les adresses IP et les adresses de groupes multicast dans les tables de routages avant la simulation. C'est au niveau IP que se passe le filtrage des paquets multicast.

3.3.4. La couche RTP

La couche RTP n'est pas encore intégrée dans la librairie INET. Dans la version 20061020, il y a une implémentation de la couche RTP réalisé par Matthias Opptiz [Oppitz, 02] et ajouté par Andras Vargas mais elle n'est pas encore intégrée. Le problème ce cette implémentation est qu'elle a été faite dans une ancienne version de l'année 2001 et que l'architecture globale de la librairie INET a changé.

3.3.5. La couche Application

De nombreuses applications sont implémentés dans la librairie INET qui utilise le protocole UDP ou le protocole FTP.

Conclusion

Tout au long de ce chapitre, nous avons vu le standard IEEE 802.11 avec ses deux couches PHY et MAC. Nous avons aussi présenté les algorithmes d'adaptation du débit de transmission physique avec certaine comparaison entre ses différents algorithmes. Ensuite, nous avons expliqué les besoins des applications temps réels ainsi que les protocoles RTP et RTCP. Nous avons présenté deux approches permettant d'améliorer la qualité de transmission

vidéo dans les réseaux IEEE 802.11. A la fin de ce chapitre nous avons présenté le niveau d'implémentation des différentes couches protocolaire du simulateur OMNET++.

Le chapitre suivant présentera une spécification de notre projet avec une analyse des besoins à l'aide de diagrammes de cas d'utilisation.

Chapitre 2 : Analyse & Spécification

Introduction

Après avoir présenté les notions de base nécessaires pour comprendre les fonctionnalités de notre projet, nous commençons ce chapitre avec une présentation de la problématique de notre projet. Ensuite, nous allons énoncer les spécifications de celui-ci en exposant les besoins fonctionnels et non fonctionnels du travail à réaliser. Enfin, nous enchaînons par la description des diagrammes de cas d'utilisation.

1. La problématique

Le but de ce projet est de simuler de nouvelles approches pour améliorer la qualité de la transmission vidéo dans les réseaux IEEE 802.11. Les simulations seront réalisées à l'aide d'une des frameworks du simulateur OMNET++. Comme nous avons déjà indiqué dans la partie état de l'art, les deux librairies MF et INET ne supporte pas la transmission multipoint. L'autre problème dans ce sujet est que les protocoles RTP et RTCP se sont pas implémentés.

2. Les besoins fonctionnels 2.1. Environnement physique

Ce travaille s'intègre dans le cadre du projet RNRT Divine. Ce dernier propose l'étude, la conception et le développement d'un système réaliste et simple permettant de diffuser des flux image et vidéo vers des terminaux mobiles hétérogènes au travers de liens hétérogènes sans fils IP. Le projet RNRT Divine vise à étudier des solutions innovantes permettant, au sein d'un système hétérogène la diffusion de vidéo et images basées sur la détection, la gestion et le traitement adaptatif de cette hétérogénéité. Cela permettra d'assurer le transfert multimédia en qualité maximale vers l'utilisateur.

2.2. Les fonctionnalités

Les fonctionnalités définissent une description abstraite des services que le système est sensé fournir. Cette description ne spécifie que le comportement extérieur et n'a rien à voir avec les caractéristiques de conception. Cependant, elle doit être à la fois complète et consistante. La complétude signifie que tous les services requis par l'utilisateur sont spécifiés et la consistance signifie qu'il n'y a pas de besoins contradictoires. Nous allons dans ce qui suit présenter les besoins de notre projet.

2.2.1 Les besoins de simulations

Le simulateur doit permettre de connecter un réseau Ethernet IEEE 802.3 avec un ou plusieurs réseaux IEEE 802.11. Il doit aussi permettre le routage des paquets multipoint au niveau IP. Les noeuds dans un réseau IEEE 802.11 auront la possibilité de se déplacer pendant

la simulation. Le simulateur doit permettre de créer un ou plusieurs flux multipoint avec d'autre flux concurrents point à point.

2.2.2. Au niveau de la couche Physique

La couche physique du simulateur doit comprendre les deux standards IEEE 802.1 1b et IEEE 802.11 a. L'utilisateur aura le choix entre les différents modèles de propagation FreeSpace, Two-Ray, Shadowing et un modèle de fading. Le simulateur doit permettre la génération d'un fichier contenant les masques d'erreurs de transmission des paquets à la fin de la simulation.

2.2.3. Au niveau de la couche MAC

Le simulateur doit permettre aux utilisateurs de choisir entre la couche MAC IEEE 802.1 1a ou bien IEEE 802.1 1b. La couche MAC doit permettre au utilisateur le choix entre les différents algorithmes d'adaptation du débit physique ARF [Kamerman et al., 07] et AARF [Lacage et al. 04]. Le simulateur doit permettre le filtrage des paquets multipoint au niveau MAC. Le simulateur doit ajouter les nouvelles trames de gestion de réseau IEEE 802.11v [Seok et al., 07]. Le point d'accès permettra de relier un réseau IEEE 802.3 et un le réseau IEEE 802.11.

2.2.4. Au niveau de la couche RTP

Le simulateur doit implémenter les protocoles temps réels RTP et RTCP afin de permettre la simulation du vidéo streaming. L'implémentation des protocoles RTP/RTCP doit être conforme au RFC 3550 [Schulzrinne, et al., 03].

2.2.5. Au niveau de la couche Application

Une application d'émission et de réception vidéo doit être implémentée dans le simulateur. Cette application émettrice prend comme paramètre un fichier contenant des trames vidéo à transmettre. Les trames vidéo peuvent être de type I, B et P. L'application réceptrice pourra reconstruire les trames envoyées par l'application émettrice.

3. Les besoins non fonctionnels

Le développement devra se conformer aux contraintes suivantes :

o Technologies utilisées : concernant l'implémentation, l'application sera développée en utilisant le langage C++ dans un environnement Linux.

o L'implémentation du fading au niveau couche physique sera réalisée à l'aide de la librairie IT++ [IT++, 07].

o Méthode de conception : la conception devra utiliser la méthode UML. Nous allons décomposer la modélisation de l'application sous deux aspects : l'aspect du modèle statique et l'aspect du modèle dynamique. UML modélise la dynamique sous forme de trois types de diagrammes :

- Diagramme de cas d'utilisation.

- Diagramme de séquences.

- Diagramme de classes.

4. Diagramme de cas d'utilisation

Les diagrammes de cas d'utilisation sont des vues externes du système. La fonctionnalité d'un cas d'utilisation peut se décomposer en un flot d'évènements. Les scénarios décrivent le comportement du système du point de vue utilisateur en termes d'actions et de réactions.

4.1. Définition du système

Notre système est le simulateur OMNET++ et plus précisément la librairie INET et la librairie MF. Ce système peut être aussi décomposé en plusieurs sous-systèmes qui seront les différentes couches protocolaires : la couche PHY, la couche MAC, la couche RTP et la couche application. L'utilisateur de notre projet est l'utilisateur du simulateur qui peut être un étudiant, un chercheur, un ingénieur etc. Dans ce qui suit, nous allons décrire uniquement les nouvelles fonctionnalités que nous lui devons ajouté.

4.1.1 Le simulateur OMNET++

Définir les connexions entre les noeuds d'un réseau

Simuler un scénario

<<include>>

<<include>>

Définir la topologie

<<include>>

Tracer les courbes

Définir la couche protocolaire pour chaque noeud

Utilisateur

Calculer les statistiques

La plate forme INET

Figure 2.1 Les cas d'utilisation du simulateur OMNET++

Les scénarios :

· Définir la topologie

- Créer un réseau avec des noeuds déjà développé dans le simulateur OMNET++. - Construire de nouveaux modules et les connecter.

· Définir la couche protocolaire

- Utiliser les noeuds déjà existantes dans le simulateur OMNET++ en spécifiant de nouveaux paramètres dans le fichier omnetpp.ini ou bien dans le fichier .ned.

· Définir les connexions entre les différents noeuds d'un réseau

- Spécifier les connexions avant la simulation dans le fichier .ned.

- Connecter les modules du réseau de façon dynamiques lors de la simulation.

· Tracer la courbe

- Tracer une courbe sur l'évolution d'un paramètre.

- Tracer une courbe de statistiques sur différentes simulations

- Superposer deux courbes dans un seul graphe pour faire les comparaisons

· Calculer les statistiques

- Enregistrer les paramètres de performance de chaque module du réseau. - Faire des statistiques sur un ensemble de simulation.

4.1.2. La couche PHY

Nous allons décrire dans cette partie les nouvelles fonctionnalités que nous avons ajoutées au modèle physique du simulateur OMNET++.

Calculer la puissance reçue

Calculer le PER

La couche PHY

Générer les masques d'erreur

Les modèles physiques

Figure 2.2 Les cas d'utilisation des modèles physiques

Les scénarios :

· Calculer la puissance reçue

- Calcul à l'aide des modèles Free Space et fading.

- Calcul à l'aide du modèle Two Ray.

- Calcul à l'aide des modèles Shadowing Model et fading.

· Calculer le BER

- Calculer le PER en fonction du modèle physique utilisé en supposant que le BER est uniforme.

- Estimer le PER en utilisant [Khalili et al., 06].

· Générer les masques d'erreur

- Créer un fichier contenant les bits erronés.

4.1.3. La couche MAC

Adapter le débit de transmission physique

PHY Layer

Sélectionner le Leader

Multicast application

Filtrer les trames multipoints

La couche MAC IEEE 802.11

Figure 2.3 Les cas d'utilisation de la MAC IEEE 802.11

Les scénarios :

· Adapter le débit

- Garder un débit physique de transmission constant.

- Sélectionner le débit de transmission physique en utilisant l'algorithme ARF. - Sélectionner le débit de transmission physique en utilisant l'algorithme AARF.

· Sélectionner le Leader

- Choisir une station non-AP connectée à un flux multicast comme Leader. - Informer une station qu'elle n'est plus Leader.

- Utiliser les trames LMBS pour choisir le Leader.

· Filtrer les trames multipoints

- Ignorer ses trames et les traiter comme les trames broadcast et le filtrage se fait au niveau IP.

- Supprimer les trames multipoints dont la station n'appartient pas à leur groupe.

4.1.4. La couche RTP

Encapsuler les messages

Adapter le débit

Application

Fournir des statistiques

Reconstruire les messages

La couche RTP/RTCP

Figure 2.4 Les cas d'utilisation de la couche RTP

Les scénarios :

· Encapsuler les messages

- Ajouter l'entête RTP au message de la couche application

- Fragmenter les messages de la couche application en deux ou plusieurs messages RTP en ajoutant le timestamp dans les entêtes pour permettre au module RTP récepteur de reconstruire les messages.

· Fournir des statistiques

- Calculer les taux de perte des paquets.

- Calculer le débit et la gigue.

· Reconstruire les messages

- Décapsuler les messages reçus de la couche UDP et les envoyer à la couche application.

- Reconstruire les trames vidéo à partir des fragments des trames vidéo envoyées.

Conclusion

Après avoir listé les besoins fonctionnels et non fonctionnels de notre projet, nous allons détailler dans le chapitre suivant la conception de notre solution à travers les diagrammes de classes ainsi que les diagrammes de séquences.

Chapitre 3 : Conception

Introduction

Ayant achevé la phase d'analyse, nous allons dégager la hiérarchie détaillée et complète des classes conçues tout en expliquant le rôle de chacune d'elles, puis nous expliquons les interactions entre elles avec les diagrammes de séquence.

1. L'architecture globale

Dans cette partie, nous allons présenter l'architecture globale des modules à développer dans ce projet. Il s'agit de l'interface réseau IEEE 802.11 et de la couche RTP/RTCP.

1.1. L'interface réseau IEEE 802.11

Nous avons ajouté l'interface IEEE 802.1 1a aux librairies MF et INET. Ce qui suit sera une description de l'architecture de cette interface.

1.1.1. L'interface réseau IEEE 802.11 de la librairie MF

L'interface réseau IEEE 802.1 1a que nous avons ajouté dans la librairie MF est un nouveau module appelé Nic8021 1a. Il est composé de 3 modules simples qui sont Decider8021 1a, SnrEcal8021 1a et Mac8021 1a. Comme le montre la figure 3.1, ce module possède deux interfaces de sortie avec la couche IP et avec le canal.

Nic80211a

Figure 3.1 Le module Nic80211a

1.1.2. L'interface réseau IEEE 802.11 de la librairie INET

L'interface réseau IEEE 802.1 1a est un module composé de 3 modules simples qui sont Ieee8021 1aRadio, Ieee8021 1aMac et Ieee8021 1Mgmt. Dans la librairie INET, nous distinguons entre deux types de cartes réseaux sans fils : celle d'une station et celle d'un point d'accès. Cette différence est au niveau module Ieee8021 1Mgmt. Ce dernier gère les paquets

de gestion (authentification, association, etc.) qui sont échangés entre le point d'accès et les autres stations.

Ieee80211aNicSTA

Figure 3.2 Les composants du module Ieee80211aNicSTA

1.2 La couche RTP/RTCP

Le module RTPLayer est composé, comme le montre la figure 3.3, de plusieurs modules qui sont : rtpModule, rtcpModule, RTPProfile, RTPPayloadReceiver et RTPPayloadSender. Ce module possède une interface avec la couche Application et deux interfaces avec la couche UDP l'une connecté avec le module simple rtpModule et l'autre avec rtcpModule.

Figure 3.3 Les composants du module RTPLayer

2. Diagramme de classes

Après avoir décrit l'architecture globale de notre projet, nous allons définir les diagrammes de classes suivant une modélisation UML.

2.1. L'interface réseau IEEE 802.11a de la librairie MF

# bitrate

#snirThreshold

# typeOfChannelForBer # d_free

# ad_free

# Ck[10]

# puncturing_period

# coderOutputBits

# FadingArrayIndex

# FadingArrayIndexInternal # codingRate

# error_masks

# CurrentGeneratedRandomNumberForMaskGeneration # minSnrForOutageProbInSlowFading

# isErrorMaskGenerated #isFadingChannelUsed # fadingNumberOfSamples # simulationBaudRate # normalizedDopplerFrequency

# averagePowerProfileDb # fadingChannelRicianFactor # typeOfChannelForBER # perCalculationMethod # phyReceiverNoiseLevel # FadingProcessCoeffs

+ initialize ( int)

+ finish ()

# handleLowerMsg (cMessage * msg) # handleUpperMsg (cMessage * msg) # handleSelfMsg (cMessage * msg) # handleLowerControl (cMessage * msg) # dB2fraction ( double)

# packetOk (double SNR, int length, double bitrate)

# bpskBER (double snirMin, double bitrate)

# QamBER (double snirMin, double bitrate, int m)

# Qfunction (double x)

# generate_error_masks (unsigned int nbits, double Pb, bool error_distribution_type, FILE * error_masks, double EER, double snr) # getSuccessRate (double snr, unsigned int nbits, FILE * error_masks, double rate)

# getSuccessRateFecBpsk (double snr, unsigned int nbits, double rate, double codingRate)

# getSuccessRateFecQam (double snr, unsigned int nbits, double rate, double codingRate, int m)

# getSuccessRateNoFecBpsk (double snr, unsigned int nbits, double rate, double codingRate)

# getSuccessRateNoFecQam ()

# increaseFadingArrayIndex ()

# getFadingFactor ()

# getBitNumbersPerModulationSymbol ( int) # erfc (double x)

: double

: double

: int

: uint32 _t

: uint32 _t

: uint32 _t

: uint32 _t

: uint32 _t

: int : int : double

: FILE *

: double

: double

: int : int : int : double

: double

: int : int : int : int : int : itpp::cmat

Decider80211a

+ initilize ()

+ handleMessage () # handleSelfMsg () # handleUpperMsg () # handleLowerMsg () # handleLowerControl () # sendDown ()

# sendUp ()

# sendControlUp ()

: void

: void

: void

: void

: void

: void

: double : bool

: double : double : double : void

: double : double : double : double : double : void

: double : uint32 _t : double

1..1

: void : void : void : void : void : int : void : void : void

1..1 1..1

# myMacAddr # timeout

# nav

# contention

# endSifs

# state

# catRadioState # medium

# defaultBitrate # bitrate

# catBitrate #autoBitrate

# rateIndex #snrThresholds # radio

# queueLength # nextIsBroadcast # fromUpperLayer # longRetryCounter # shortRetryCounter # successCounter # failedCounter # recovery

# timer

# successThreshold

# maxSuccessThreshold # timerTimeout

# minSuccessThreshold # minTimerTimeout

# successCoeff # timerCoeff

# handleSelfMsg (cMessage* msg) # handleUpperMsg (cMessage* msg) # handleLowerMsg (cMessage* msg) # handleLowerControl (cMessage* msg) # setBitrate (double b_rate)

# getBitrate ()

# needNormalFallback ()

# needRecoveryFallback ()

# reportFailure ()

# reportRecoveryFailure ()

# setSuccessThreshold (int success_threshold) # setTimerTimeout (int timer_timeout)

# getSuccessThreshold ()

# getTimerTimeout ()

# getMinSuccessThreshold ()

# getMinTimerTimeout ()

# reportDataFailed ()

# reportDataOk ()

# getMinBitrate ()

# getMaxBitrate ()

# getTimeout ()

# retrieveBitrate (int destAddress)

# packetDuration (double bits, double br) # decapsMsg (Mac80211Pkt * frame)

# encapsMsg (cMessage * netw) # sendBROADCASTframe ()

# sendRTSframe ()

# sendCTSframe ( Mac80211Pkt*) # sendACKframe ( Mac80211Pkt*) # sendDATAframe ( Mac80211Pkt*)

1..1

+ initialize ()

+ handleMessage () # encapMessage () # calcDuration ()

Mac80211a

: int

: cMessage*

: cMessage*

: cMessage*

: cMessage*

: State

: int

: MediumIndication::States : double

: int : int : int : int : std::vector<double

: SingleChannelRadio*

: unsigned

: bool

: MacPktList

: unsigned

: unsigned

: int : int : bool : int : int : int : int : int : int : double

: double

: void : void

: AirFrame80211 * : double

: void : void : void : void : void : double

: bool : bool : void : void : void : void : int

: int

: int

: int

: void : void : int

: int

: int

: double

: double

: cMessage*

: Mac80211Pkt* : void

: void : void : void : void

1..1

1..1

SnrEvala

BasicSnrEval

# snrInfo : SnrStruct

# recvBuff : std::map<AirFrame*,double>

# radioState : RadioState::States

# catRadioState : int

# rssi : RSSI

# catRSSI : int

# publishRSSIAlways : bool

# indication : MediumIndication

# catIndication : int

# nicModuleId : int

# noiseLevel : double

# recvTime : double

# waveLength : double

# thermalNoise : double

# pathLossAlphaHalf : double

# speedOfLight : double

# useTorus : bool

# playground : Coord

# bitrate : double

# catBitrate : int

# rGain : double

# propagationModelType : int

# ht : double

# hr : double

# systemLoss : double

# pathLossExponent : double

# shadowingVariance : double

# shadowing : double

# shadowingRandomNumberVectorIndex : int

# shadowingRandomNumberVector : itpp::vec

+ initialize () : int

+ receiveBBItem () : int

# handleLowerMsgStart () : int

# handleLowerMsgEnd () : int

#calcRcvdPower () : int

# calcPathLoss () : int

# addNewSnr () : int

# handlePublish () : int

# modifySnrList () : int

# calcDuration (cMessage* m) : double #updateSensitivity () : int

2.1.1. La classe Mac80211a

La classe Mac8021 1a est une implémentation de la norme IEEE 802.1 1a. Nous nous sommes basés sur [802.11, 99] [802.1 1a, 00] pour extraire les différents paramètres comme le calcul de la durée de transmission packetDuration(), la taille la fenêtre de contention et les durées des périodes ST, SIFS, DIFS, EIFS.

# myMacAddr # timeout

# nav

# contention

# endSifs

# state

# catRadioState # medium

# defaultBitrate # bitrate

# catBitrate

# autoBitrate

# rateIndex

# snrThresholds # radio

# queueLength

# nextIsBroadcast # fromUpperLayer # longRetryCounter

# shortRetryCounter

# successCounter # failedCounter # recovery

# timer

# successThreshold

# maxSuccessThreshold # timerTimeout

# minSuccessThreshold # minTimerTimeout

# successCoeff # timerCoeff

: int

: cMessage*

: cMessage*

: cMessage*

: cMessage*

: State

: int

: MediumIndication::States : double

: int : int : int : int : std::vector<double

: SingleChannelRadio*

: unsigned

: bool

: MacPktList

: unsigned

: unsigned

: int : int : bool

: int : int : int : int : int : int : double

: double

# handleSelfMsg (cMessage* msg) # handleUpperMsg (cMessage* msg) # handleLowerMsg (cMessage* msg)

# handleLowerControl (cMessage* msg) # setBitrate (double b_rate)

# getBitrate ()

# needNormalFallback ()

# needRecoveryFallback ()

# reportFailure ()

# reportRecoveryFailure ()

# setSuccessThreshold (int success_threshold) # setTimerTimeout (int timer_timeout)

# getSuccessThreshold ()

# getTimerTimeout ()

# getMinSuccessThreshold ()

# getMinTimerTimeout ()

# reportDataFailed ()

# reportDataOk ()

# getMinBitrate ()

# getMaxBitrate ()

# getTimeout ()

# retrieveBitrate (int destAddress)

# packetDuration (double bits, double br) # decapsMsg (Mac80211Pkt * frame)

# encapsMsg (cMessage * netw) # sendBROADCASTframe ()

# sendRTSframe ()

# sendCTSframe ( Mac80211Pkt*) # sendACKframe ( Mac80211Pkt*) # sendDATAframe ( Mac80211Pkt*)

: void : void : void : void : void : double

: bool : bool : void : void : void : void : int

: int

: int

: int

: void : void : int

: int

: int

: double

: double

: cMessage*

: Mac80211Pkt* : void

: void : void : void : void

Mac80211a

La classe Mac 802 11a est une classe dérivée de la classe BasicLayer de la librairie MF et correspond au module simple MAC8021 1a. Parmi les paramètres du Module Mac8021 1a nous citons queueLength qui est la capacité de sa file d'attente, bitrate qui est le débit physique utilisé et autoBitrate qui peut avoir une des trois valeurs 0,1 ou 2. La valeur 0 du paramètre autoBitrate correspond à une transmission avec un débit physique constant, alors que la valeur 1 correspond à l'algorithme ARF et 2 à l'algorithme AARF. Mac8021 1a contient aussi les différents paramètres pour chacun de ces derniers algorithmes comme timerTimeout et successThreshold pour ARF, successCoeff timerCoeff et maxSuccessThreshold pour AARF.

2.1.2. La classe SnrEval80211a

La classe SnrEval8021 1a est une classe dérivée de la classe SnrEvala. Elle permet de calculer la durée de transmission d'un paquet à l'aide de la méthode calcDuration() et aussi la puissance reçue par la méthode calcRcvdPower(). Le calcul de la puissance reçue dépend du model de propagation.

# snrInfo

# recvBuff

# radioState

# catRadioState

# rssi

# catRSSI

# publishRSSIAlways

# indication

# catIndication # nicModuleId # noiseLevel

# recvTime

# waveLength # thermalNoise

# pathLossAlphaHalf

# speedOfLight # useTorus

# playground # bitrate

# catBitrate # rGain

# propagationModelType

# ht

# hr

# systemLoss

# pathLossExponent

# shadowingVariance

# shadowing

# shadowingRandomNumberVectorIndex # shadowingRandomNumberVector

: SnrStruct

: std::map<AirFrame*,double> : RadioState::States

: int

: RSSI

: int

: bool

: MediumIndication

: int

: int

: double : double : double : double : double : double : bool

: Coord : double : int

: double : int

: double : double : double : double : double : double : int

: itpp::vec

+ initialize ()

+ receiveBBItem ()

# handleLowerMsgStart ()

# handleLowerMsgEnd ()

# calcRcvdPower () # calcPathLoss ()

# addNewSnr ()

# handlePublish () # modifySnrList ()

# calcDuration (cMessage* m) # updateSensitivity ()

: int : int : int : int : int : int : int : int : int : double : int

SnrEvala

Le module SnrEval8021 1 correspond à la classe SnrEval8021 1a. Il a comme paramètre la taille de l'entête headerLength et le bruit thermique thermalNoise, etc. Nous avons ajouté à ce module de nouveaux paramètres comme propagationModelType qui peut avoir trois valeurs possibles 0, 1, 2. La valeur 0 correspond au modèle Free-Space. La valeur 1 correspond au modèle Two-Ray. La valeur 2 correspond au modèle Shadowing. Nous avons aussi ajouté les paramètres de chaque modèle de propagation comme pathLossExponent, shadowingVaraince et shadowingNumberofSamples pour le modèle Shadowing.

SnrEval80211a

Gates:

in: uppergateIn

out: uppergateOut in: radioIn

out: upperControlOut

Figure 3.7 Le module SnrEval80211a

2.1.3. La classe Decider80211a

Cette classe décide si le paquet est correctement reçu à l'aide de la méthode isReceivedCorrectly(). Cette dernière fait appel à la méthode packetOK() qui retourne true si le paquet est correctement reçu et false dans le cas contraire. La méthode packetOK() prend comme paramètre le débit avec lequel a été envoyé le paquet afin de connaître la modulation utilisée pour envoyer le payload. Selon la modulation, elle calcule la probabilité de succès des deux morceaux du paquet et ensuite le PER. Enfin, elle génère un nombre aléatoire entre 0 et 1 et le compare au PER pour décider s'il y a eu des erreurs de transmission. Cette classe génère les masques d'erreur à l'aide de la méthode generate_error_masks(). L'appel à cette méthode se fait à chaque réception d'un nouveau paquet.

Decider80211a

# bitrate

# snirThreshold

# typeOfChannelForBer # d_free

# ad_free

# Ck[10]

# puncturing_period # coderOutputBits

# FadingArrayIndex

# FadingArrayIndexInternal # codingRate

# error_masks

# CurrentGeneratedRandomNumberForMaskGeneration # minSnrForOutageProbInSlowFading

# isErrorMaskGenerated # isFadingChannelUsed

# fadingNumberOfSamples # simulationBaudRate

# normalizedDopplerFrequency

# averagePowerProfileDb

# fadingChannelRicianFactor # typeOfChannelForBER

# perCalculationMethod # phyReceiverNoiseLevel # FadingProcessCoeffs

: double

: double

: int

: uint32_t

: uint32_t

: uint32_t

: uint32_t

: uint32_t

: int : int : double

: FILE *

: double

: double

: int : int : int : double

: double

: int : int : int : int : int : itpp::cmat

+ initialize ( int) : void

+ finish () : void

# handleLowerMsg (cMessage * msg) : void

# handleUpperMsg (cMessage * msg) : void

# handleSelfMsg (cMessage * msg) : void

# handleLowerControl (cMessage * msg) : void

# dB2fraction ( double) : double

# packetOk (double SNR, int length, double bitrate) : bool

# bpskBER (double snirMin, double bitrate) : double

# QamBER (double snirMin, double bitrate, int m) : double

# Qfunction (double x) : double

# generate_error_masks (unsigned int nbits, double Pb, bool error_distribution_type, FILE * error_masks, double EER, double snr) : void

# getSuccessRate (double snr, unsigned int nbits, FILE * error_masks, double rate) : double

# getSuccessRateFecBpsk (double snr, unsigned int nbits, double rate, double codingRate) : double

# getSuccessRateFecQam (double snr, unsigned int nbits, double rate, double codingRate, int m) : double

# getSuccessRateNoFecBpsk (double snr, unsigned int nbits, double rate, double codingRate) : double

# getSuccessRateNoFecQam () : double

# increaseFadingArrayIndex () : void

# getFadingFactor () : double

# getBitNumbersPerModulationSymbol ( int) : uint32_t

# erfc (double x) : double

Figure 3.8 La classe Decider80211a

Le module Decider8021 1a reçoit les paquets du module SnrEval8021 1a et les transmet au module Mac8021 1a. Les paramètres principaux de ce modules sont : isErrorMaskGenerated qui vaut 1 s'il y a génération d'un fichier de masques d'erreur, isFadingChannelUsed qui vaut 1 si le modèle fading est utilisé. Ce module contient aussi d'autres paramètres pour le calcul du BER et du PER.

Decider80211a

Figure 3.9 Le module Decider80211a

2.2. L'interface réseau IEEE 802.11a de la librairie INET

Après avoir bien expliqué les classes de la couche MAC et PHY de la librairie MF, nous allons décrire les classes de ces deux couches que nous avons ajoutées à la librairie INET. Nous commençons par la couche PHY, ses différentes classes et ensuite la couche MAC 802.11.

2.2.1 Le diagramme des classes de la couche PHY

La figure 3.10 représente le diagramme de classe de la couche PHY de la librairie

INET.