Memoire de Master2 Approche Efficace Pou

UNIVERSITÉ DE YAOUNDÉ I UNIVERSITY OF YAOUNDÉ I
**************** ****************
FACULTÉ DES SCIENCES FACULTY OF SCIENCES
**************** ****************
DÉPARTEMENT DEPARTMENT OF
D’INFORMATIQUE COMPUTER SCIENCES
PROBLEMATIQUE DE L’INTEGRATION DE LA
VOIX ET DU TEXTE DANS UN
ENVIRONNEMENT SANS FILS :
APPLICATION A LA TECHNOLOGIE
BLUETOOTH.
MEMOIRE DE MASTER II INFORMATIQUE

Rédigé et présenté par :
NONO LOUENKAM Guy Gaspard

Maitre es-science
Matricule : 09U0413
Sous la direction de :
Dr. Thomas DJOTIO NDIÉ

LIRIMA, Université de Yaoundé I
ANNEE ACCADEMIQUE 2012-2013

Téléphonie par Bluetooth
REMERCIEMENTS
 Je remercie tous les enseignants du Département d’informatique de la Faculté des sciences et de

l’Université de Yaoundé I pour tous les enseignements reçus durant ma formation.
 Je tiens à remercier tout particulièrement mon encadreur Dr Thomas DJOTIO NDIÉ, pour son
suivi constant, ses conseils pratiques et ses suggestions régulières qui m’ont encouragé et m’ont
permis de mener à terme mon travail.
 Au Pr. Claude TANGHA pour m’avoir offert un cadre de recherche au sein de son Département à
l’Ecole Nationale Supérieure Polytechnique.
 À tous les membres du jury qui ont accepté évaluer ce travail.
 À mon très chère père Mr. LOUENKAM Edouard pour son soutien spirituel et moral constant, ses
conseils et ses réactions spontanées dans la résolution de mes problèmes durant tout mon parcourt
scolaire.
 À tous mes camarades du laboratoire LIRIMA et particulièrement de l’équipe-projet MASECNESS
particulièrement, Rodrigue Domga, Woffo Autin, Judith, Josseline pour leurs critiques et
suggestions constructives au cours des différents exposés au sein de l’équipe.
 À tous mes camarades de MASTER II promotion 2010-2011 notamment : Wilfried, Demanou,
Vergez, Arthur, Cédric, Christian Ngono, Franklin, Silvère, Carole, Olivier, Luc, Nguimza,
Maxime, Achille Didier, Ritter, Gille, Adamou, Willy, .
 À tous les étudiants de l’école polytechnique et du Géni-Informatique en particulier pour leur
agréable compagnie
 A Serge Talom, Thiery, Stella, Anny, Dr Takam, Achille Nguenkam, Chifor, Laeticia, Natalie,
Agath, Logamou, Dermas, et tous les amis de PV et Megasoft.
 À mes maman PIEKAP Céline et TCHAYO Sidonie Laure pour leur soutien morale.
 À ma très chère tante et maman KAYOU Elisabeth qui n’a cessé de nous soutenir ma famille et moi
malgré les diverses médisances.
 À ma bien aimé grande sœur TEKAP LOUENKAM Anne Raïssa, son marie Titti et mes nièces
Lisa, Séréna et Christina pour tout leur soutien.
 À la grande Famille YIMDJEU notamment le père YIMDJEU André, maman Célestine, Nadège,
Gaëlle, Pascaline, Junior, Kelly, Anderson, Brenda, Fabiola, Franck, Clara, Belmondo, Alain, pour
leur soutien et l’atmosphère toujours détendu qu’ils ont entretenu autour de moi dans leur maison.
 À tous mes petits frères et sœurs Line, Liliane, Pepe, Franck, Brenda, Cendra, Diane, Duran,
Ennice, Armel, Julie.
 À toute ma famille: Oncle, Tantes, Cousins, Cousines, en particulier P. Mathieu, P. André, P.
Martin, P. Apollinaire, P. T. Carine, Alain, Francis, Landry, Alas.
 Mes amis Pierre Désiré Kapale, Vermon, Diego, Didier Ndass, Diebo, Arnaud, Romeo, Salomon,
Martial, Brice, Charlène, Natalie, Nicaise, Oscar, Spensy, Olivier, Michelle, Carine, Diane, Kadafi,
Kotto, Zutter, Carlos, Louh Soulé, Jandel, Samy, Kant, Aubery, pour leur soutien et leur agréable
compagnie.
 A tous mes voisins, Patrick, Charly, Yvette, Blaise, Brice, Armelle, Vivien, Liliane, Pamela, Marie,
Rachelle et sa fille Naomi et tous les autres.
 L’abbé Théophile qui m’a permis de connaitre le Chris à travers le baptême et la communion.
 Aux chefs des groupements Bangang Fondji et Moutcha
 A mon maître, Mr. Inoussa sans qui je ne serais arrivé.
 A tous mes professeurs du lycée de Koutaba pour leurs enseignements et leurs encadrements.
 À tous ceux qui de près ou de loin m’ont soutenu et ont contribué à l’acheminement de ce travail.
Mémoire de Master II 1 NONO LOUENKAM Guy Gaspard

DEDICACES
A mon père Mr. LOUENKAM Edouard

A ma mère PIEKAP Céline et TCHAYO Sidonie Laure
A ma tante et maman Mme WETE KAYOU Elisabeth
A ma grande sœur TEKAP LOUENKAM Anne Raïssa
A Papa. YIMDJEU André
A tous mes petits frères et sœurs
Et à tous ceux qui me sont chères,
ce travail vous est dédié.

RESUME
Les télécommunications occupent une place importante dans le quotidien des hommes qui ont de
plus en plus besoin de communiquer, d'échanger des informations, à n'importe quel moment,
quelques soit l’endroit où ils se trouvent, avec des exigences plus ou moins accrues sur la qualité
des transmissions. Le secteur des télécommunications sans fil a connu une évolution considérable
ces deux dernières décennies dans le monde avec la naissance de plusieurs solutions comme le
GSM, l’UMST, le Wifi, le Bluetooth et bien d’autres. Mais seulement, le cout de déploiement et
l’accès aux équipements utilisés par ces solutions représentent des obstacles pour les pays en voie
de développement qui souffrent toujours des problèmes de couverture et d’accès réseau dans
certaines zones.
Pour contribuer à pallier à ces manquements, nous avons proposé une solution de téléphonie
basée sur la technologie Bluetooth qui regorge de plusieurs atouts et qui est en perpétuelle
évolution. Pour cela, nous avons défini une architecture de communication basée sur des concepts
nouveaux comme les nœuds Bluetooth que nous étions contraints de définir en raison de la
particularité de notre solution qui faisait face à la faible portée du Bluetooth (100 mètres pour les
émetteurs de classe I) et aux contraintes liées à la gestion de la voix. Ceci a conduit à la définition
de deux protocoles l’un de formation de scatternet entre les nœuds Bluetooth et l’autre de routage
que nous avons validé en utilisant l’outil de validation formelle AVISPA. Nous avons ensuite conçu
et réalisé une application de communication qui permet une transmission bidirectionnelle des flux de
voix entre deux périphériques Android par Bluetooth.
Néanmoins, la conception et la fabrication des nœuds routeurs comme des périphériques à part
entieres, la gestion de la sécurité dans les communications et la gestion de la mobilité entre les
périphériques Bluetooth sont des améliorations à faire dans les travaux futurs en vue de mettre sur
pied une plate-forme de téléphonie complète et plus abouti comme celle du GSM.
Mots clés: Bluetooth, téléphonie, voix, nœuds routeur, protocole, routage, synchronisation,
piconet, scatternet

ABSTRACT
Telecommunications occupies an important place in the lives of men who increasingly need to
communicate, exchange information, at any time, some of where they are, with more or less
demands increased quality transmissions. The area of wireless communications has evolved
considerably over the last two decades in the world with the birth of several solutions such as GSM,
UMST, Wi-Fi, Bluetooth and many more. But only the cost of deployment and access to equipment
used by these solutions represent barriers for developing countries which still suffer of network
coverage and network access problems in some areas.
To help overcome these shortcomings, we have proposed a telephony solution based on
Bluetooth technology packed with several advantages and is constantly evolving. For this, we
defined a communication architecture based on new concepts such as Bluetooth router nodes that
we were forced to define due to the uniqueness of our solution which faced the narrow scope of
Bluetooth (100 meters for issuers class I) and constraints related to the voice management. This has
led to the definition of two protocols one of scatternet formation between nodes Bluetooth and other
routing that we validated using the AVISPA formal validation tool. We then designed and
implemented a communications application that allows bidirectional transmission of voice streams
between two Android devices via Bluetooth.
However, the design and manufacture of devices such as router nodes, the management of
security in communications and mobility management between Bluetooth devices are
improvements to be made in future works to develop a complete and resulted telephony platform
like GSM.
Keywords: Bluetooth, telephony, voice, router nodes, protocol, routing, synchronization,
piconet, scatternet.

GLOSSAIRE
 ACL : Asynchronous Connection-Less  IARP (IntrAzone Routing Protocol) : protocole
 AES : Advanced Encryption Standard utilisé par le protocole ZRP pour les
 communications locales à une zone

ARPANET : Advanced research Project
IBSS : Independent Basic Service Set

Agency Network: réseau à commutation de
paquet mis en place en 1969 et qui donna IEEE : Institute of Electrical and Electronics
naissance à Internet. Engineers
 BBS : Bluetooth Base Station  IERP : IntErzone Routing Protocol) : protocole
 BD_ADDR : Bluetooth Device Address: C’est utilisé par le protocole ZRP pour les
l’adresse matérielle des périphériques Bluetooth communications entre les zones
équivalent à l’adresse Mac d’une carte réseau.  ISM : Industrial, Scientific and Medical :
Ces adresses sont codées sur 48bits et sont bandes de fréquences libres utilisés dans des
gérées par l’IEEE Registration Authority. cadre scientifiques, industriels et medicales
 BSC : Base Station Controller  L2CAP : Logical Link Control & Adaptation
 Protocol

BSS : Base station Subsystem
 BSS(2) : Basic Service Set [NEI 10] MIMO : Multiple-Input Multiple-Output)
 BTCP : Bluetooth Topologie Control  OFDM : Orthogonal Frequency Division
Protocol : c’est un protocole de formation de Multiplexing).
scatternet dans les réseaux Bluetooth.  OLSR: Optimized link state routing
 BTS : Base Transceiver Station protocol
 CEPT : Conférence Européenne des  PAN : Personal Area Network
administrations des Postes et  PCI : Peripheral Component Interconnect
Télécommunications 

PCMCIA : personal computer Memory Card
CRC : contrôle de redondance cyclique

International Association
DBF : Distributed Bellman-Ford 

RATP : Régie autonome des transports parisiens
DSDV : Destination-Sequenced Distance Vector 

SCO : Synchronous Connection-Orientated
EBSS : Extended Basic Service Set 

SIG : Bluetooth Special Interest Group
FHSS : Frequency Hope Spread Spectrum), 

SMS : Short Message Service
F-TDMA: Frequency Time Division Multiple  TTL (Time To Live)
Access 

USB : Universal Serial Bus
GPRS: General Packet Radio Service 

VoIP: Voice Over Internet Protocol, également
GSM : Global System for Mobile appelée téléphonie IP ou téléphonie sur Internet.
Communication 

WAP : Wireless Application Protocol
HCI : Host Control Interface : fait le lien entre  WECA : Wireless Ethernet Compatibility
la couche physique et la couche applicative de la Alliance
pile de protocole Bluetooth. 

Wi-Fi : Wireless Fidelity
i.e. : c’est-à-dire  WWiSE : World-Wide Spectrum Efficiency
 ZRP (Zone Routing Protocol)

TABLE DES MATIERES

MEMOIRE DE MASTER II INFORMATIQUE ........................................................................... 1
REMERCIEMENTS ....................................................................................................................... 1
DEDICACES .................................................................................................................................. 2
RESUME ......................................................................................................................................... 3
ABSTRACT .................................................................................................................................... 4
GLOSSAIRE ................................................................................................................................... 5
TABLE DES MATIERES .............................................................................................................. 7
LISTE DES FIGURES .................................................................................................................. 10
LISTE DES TABLEAUX ............................................................................................................. 11
LISTE DES ALGORITHMES ...................................................................................................... 11
CHAPITRE I. INTRODUCTION GENERALE ........................................................................ 12
I.1. CONTEXTE .................................................................................................................... 12
I.2. PROBLEMATIQUE........................................................................................................ 12
I.3. MOTIVATIONS ET OBJECTIFS .................................................................................. 13
I.4. LES DOMAINES D’APPLICATIONS DE LA TELEPHONIE PAR BLUETOOTH... 13
I.4.1. Application dans le domaine universitaire ............................................................... 14
I.4.2. Applications dans le domaine de la santé ................................................................. 14
I.4.3. Application dans le domaine administratif et en entreprise ..................................... 14
I.4.4. Application dans le domaine de la sécurité de proximité ......................................... 15
I.4.5. Application dans le domaine de la publicité ............................................................ 15
I.5. BILAN ............................................................................................................................. 15
I.6. STRUCTURE DU MEMOIRE ...................................................................................... 15
CHAPITRE II. ETAT DE L’ART .............................................................................................. 17
II.1. LE GSM ..................................................................................................................... 17
II.1.1. Description ............................................................................................................ 17
II.1.2. Les services offerts par le GSM............................................................................ 18
II.1.3. Les limites du GSM .............................................................................................. 18
II.2. LE WI-FI: WIRELESS FIDELITY ........................................................................... 18
II.2.1. Description du Wi-Fi ............................................................................................ 18
II.2.2. Application du Wi-Fi liée à la téléphonie : La VoIP ............................................ 22
II.2.3. Les limites du Wi-Fi ............................................................................................. 22
II.3. LE WI-FI DIRECT .................................................................................................... 22

II.4. L’INFRAROUGE ...................................................................................................... 23

II.5. LE BLUETOOTH ...................................................................................................... 24
II.5.1. Historique ............................................................................................................. 24
II.5.2. Les différentes normes Bluetooth ......................................................................... 24
II.5.3. La pile de protocole Bluetooth ............................................................................. 24
II.5.4. Les avantages du Bluetooth par rapport à nos objectifs ....................................... 29
II.5.5. Les applications téléphoniques liées à la technologie Bluetooth.......................... 29
II.6. BILAN DU CHAPITRE ............................................................................................ 30
CHAPITRE III. PRESENTATION DE LA SOLUTION .......................................................... 31
III.1. INTRODUCTION ..................................................................................................... 31
III.2. ANALYSE DES CONTRAINTES PARTICULIERES LIEES A LA TELEPHONIE
PAR BLUETOOTH. ...................................................................................................................... 31
III.2.1. Contraintes technologiques ................................................................................... 31
III.2.2. Contrainte applicatives et en qualité de service (QoS) ......................................... 32
III.2.3. Les contraintes de généricité ................................................................................ 32
III.3. APPROCHE ET MODELE DE LA SOLUTION...................................................... 33
III.3.1. Présentation de l’approche .................................................................................... 33
III.3.2. Présentation des deux cas de communications ..................................................... 34
III.3.3. Description du nœud routeur (NR) « point d’accès » Bluetooth .......................... 35
III.4. ARCHITECTURE DE LA PLATE-FORME ............................................................ 36
III.4.1. Architecture graphique étendue de notre solution ................................................ 36
III.4.2. Protocole de formation des scatternet ................................................................... 38
III.4.3. Protocole de routage ............................................................................................. 42
III.5. ETUDE DES ENJEUX ECONOMIQUES DE LA SOLUTION. ............................. 46
CHAPITRE IV. MISE EN ŒUVRE DE LA SOLUTION ........................................................ 48
IV.1. Analyse des besoins ................................................................................................... 48
IV.1.1. Besoins fonctionnels ............................................................................................. 48
IV.1.2. Besoin non fonctionnels ....................................................................................... 49
IV.1.3. Ressources (matérielles, logiciel, humaines) ........................................................ 49
IV.2. Présentation de la plateforme Android....................................................................... 49
IV.3. Conception de l’application ....................................................................................... 49
IV.3.1. Acteur du système................................................................................................. 49
IV.3.2. Diagramme d'états ................................................................................................ 50
IV.3.3. Diagramme de séquence utilisateur/application ................................................... 51

IV.4. Architecture logicielle ................................................................................................ 52

IV.5. Implémentation de l’application ................................................................................ 52
IV.5.1. Définition des droits ............................................................................................. 53
IV.5.2. Recherche des équipements .................................................................................. 54
IV.5.3. Pairage et connexion de deux équipements .......................................................... 54
IV.5.4. Gestion de la communication vocale .................................................................... 55
IV.5.5. Le Multi langues .................................................................................................. 57
IV.6. BILAN DU CHAPITRE ............................................................................................ 58
IV.6.1. Difficultés rencontrés............................................ Error! Bookmark not defined.
IV.6.2. Limites du SDK Android ...................................... Error! Bookmark not defined.
CHAPITRE V. VALIDATION DU PROTOCOLE ................................................................... 59
V.1. Présentation de la plateforme AVISPA ..................................................................... 59
V.2. Les bases du langage HPLS ....................................................................................... 60
V.3. Modélisation de notre protocole de routage BRProtocol en langage HPLS .............. 60
V.3.1. Notation A-B ........................................................................................................ 61
V.3.1. Le rôle du nœud source......................................................................................... 61
V.3.2. Le rôle du nœud routeur ....................................................................................... 61
V.3.3. Rôle du nœud destinataire .................................................................................... 62
V.3.4. La session de communication ............................................................................... 62
V.3.5. L’environnement de communication .................................................................... 62
V.4. Exécution sous AVISPA ............................................................................................ 63
V.5. Simulation avec l’outil SPAN : .................................................................................. 64
V.6. BILAN ....................................................................................................................... 65
CONCLUSION GENERALE ....................................................................................................... 66
PERSPECTIVES ........................................................................................................................... 66
PUBLICATION SCIENTIFIQUE ................................................................................................ 67
Articles de conférences internationales avec actes et comité de lecture ................................... 67
ANNEXE A : LES BASES DU LANGAGE HPLS ..................................................................... 68
1. Définition des rôles .................................................................................................... 68
2. Transitions .................................................................................................................. 68
3. Les rôles composés .................................................................................................... 69
4. L’environnement du système ..................................................................................... 69
ANNEXE B : PREUVES DES RELATIONS (1) ET (2) ............................................................. 70
Preuve de la relation (1) : ....................................................................................................... 70

Preuve de la relation (2) : ......................................................................................................... 70

ANNEXE C : PRESENTATION DE LA PLATE-FORME ANDROID ..................................... 71
5. Caractéristiques : ........................................................................................................ 71
6. Particularité : .............................................................................................................. 71
7. Environnement de développement : ........................................................................... 71
8. Emulateur Android :................................................................................................... 71
9. Langages de développement sous Android:............................................................... 71
10. Android Market: ......................................................................................................... 71
11. Achitecture de la plateforme Android :...................................................................... 72
REFERENCES BIBLIOGRAPHIQUES ...................................................................................... 72
LISTE DES FIGURES

Figure 1 : Le mode infrastructure wifi ........................................................................................................................ 20
Figure 2 : Le mode de fonctionnement Ad Hoc du Wi-Fi .......................................................................................... 21
Figure 3: répéteur wifi ................................................................................................................................................ 21
Figure : Exemples de points d’accès Wi-Fi .............................................................................................................. 22
Figure 5 : télécommande à infrarouge ......................................................................................................................... 23
Figure 6 : La pile de protocole Bluetooth ..................................................................................................................... 25
Figure 7 : piconet ........................................................................................................................................................ 28
Figure 8 : Scatternet.................................................................................................................................................... 28
Figure 9 : puce Bluetooth (14×36×4 mm) ................................................................................................................... 29
Figure 11 : A et B sont couverts par le même nœud routeur ...................................................................................... 33
Figure 12: A et B ne sont pas couverts par le même nœud routeur ............................................................................ 33
Figure 13: communication P2P entre deux périphériques .......................................................................................... 35
Figure 14: Example of Bluetooth hub .......................................................................................................................... 36
Figure : Exemple de nœud routeur appelé BTS Bluetooth ...................................................................................... 36
Figure 16: Architecture graphique étendue de notre solution .................................................................................... 37
Figure 17 : exemple d'un réseau ad-hoc ...................................................................................................................... 43
Figure 18: communication point à point entre deux utilisateurs A et B .................................................................... 48
Figure 19: diagramme des cas d'utilisations ............................................................................................................... 48
Figure 20: diagramme d'état de notre application ...................................................................................................... 50
Figure 21: diagramme de séquence utilisateur/application ......................................................................................... 51
Figure 22: Architecture logiciel .................................................................................................................................. 52
Figure 23: exemple d'émulateur ................................................................................................................................. 71
Figure : Architecture interne d ’Android ................................................................................................................ 72

LISTE DES TABLEAUX

Table 1: Les différentes classes d'émetteurs Bluetooth ................................................................................................ 25
Table 2 : table de routage correspondant au nœud M dans le graphe ci-dessus ........................................................ 43
Table : RECAPUTULATIF estimation d’un nœud routeur ..................................................................................... 47
Table 4: estimation du déploiement de l'application dans un campus universitaire .................................................. 47
LISTE DES ALGORITHMES

Algorithme 1: création du canal de communication entre deux points A et B qui souhaitent communiquer ............ 34
Algorithme 2: fichier AndroidManifest.mf ................................................................................................................. 53
Algorithme 3: recherche des équipements ................................................................................................................... 54
Algorithme 4: connexion des équipements .................................................................................................................. 55
Algorithme 5: enregistrement du son ......................................................................................................................... 56
Algorithme 6: envoi du son par Bluetooth .................................................................................................................. 56
Algorithme 7: envoi du son par Bluetooth (2)............................................................................................................. 56
Algorithme 8: lecture du son chez l'interlocuteur ...................................................................................................... 57
Algorithme 9: capture de l'audio ................................................................................................................................ 57
Algorithme 10: gestion du Multilingue ...................................................................................................................... 58

CHAPITRE I. INTRODUCTION GENERALE
I.1. CONTEXTE
Le domaine de la télécommunication a connu ces 20 dernières années des évolutions

considérables dans le monde en générale et dans les pays en voie de développement en particulier.
Il est indéniable que cette évolution, passe par les systèmes de communication sans fils (basés
essentiellement sur la transmission radio) qui, se démarquent de plus en plus des autres systèmes de
communication à travers les diverses recherches et investissements menés par les différents
laboratoires et organismes spécialisés dans le domaine, qui poussent de plus en plus leurs
recherches afin de développer des technologies encore plus innovantes dans ce secteur depuis la fin
des années 1980. Avec la multiplication des dispositifs mobiles (téléphones portables, tablettes,
PDA, Smartphones, et bien d’autres) à travers le monde, les réseaux mobiles ont vu leur nombre
d’abonnés et leurs revenus se multiplier de façon considérable depuis début des années 1990.
Ceci dit, plusieurs solutions de communication sans fil existent de nos jours parmi lesquelles :
le GSM [MAR 01], le GPRS (General Packet Radio Service)1, l’UMTS (universal mobile
telecommunication system), le Wi-Fi2, le Wi-Fi direct [WIF 10], l’infrarouge et le Bluetooth. Les 3
premières technologies (GSM, GPRS, UMTS), sont beaucoup plus adaptées aux communications
longues portées et nécessitent des équipements importants et des installations fastidieuses pour leur
déploiement et pour leur mise en œuvre. Pour le cas du Wi-Fi et le Wi-Fi Direct3, bien qu’offrant
des services conséquents en matière de communication sans fil, ils ont tout de même de nombreuses
limites : le Wi-Fi malgré son bon débit et sa longue portée est limité par son coût, son
encombrement et sa forte consommation d’énergie ; le Wi-Fi Direct, ayant hérité des propriétés du
Wi-Fi classique a du même coup hérité des principaux inconvénients de ce dernier en plus du fait
qu’il ne soit pas encore assez rependu dans le domaine de la téléphonie. L’infrarouge pour sa part,
bien que consommant très peu d’énergie électrique, est limité par sa très faible portée (quelques 5 à
10 mètres seulement) et par les perturbations dû aux interférences lumineuses car les infrarouges ne
peuvent passer à travers les objets i.e. les appareils à relier doivent donc être en contact visuel4
[DAV 00]. La dernière, le Bluetooth lancé en 1994 par le constructeur Ericsson, est une technologie
qui regorge d’atouts et qui palie à certaines limites présentées par ses prédécesseurs de par la petite
taille et le faible coût en prix et en énergie consommée de sa puce. En plus de cela, il offre plusieurs
services de communication sans fils de proximité parmi lesquels le transfert de fichier, la connexion
de périphérique sans fils entre eux et aussi de la téléphonie de proximité qui retiendra
particulièrement notre attention dans la suite.
I.2. PROBLEMATIQUE
Même s’il est avéré que le secteur des télécommunications a connu une remarquable évolution
dans le monde ces 20 dernières années, les problèmes de coûts de communication et de couverture
réseau, constituent toujours un défi majeur pour les pays en voie de développement. Le Bluetooth
1
http://fr.wikipedia.org/wiki/General_Packet_Radio_Service
2
http://fr.wikipedia.org/wiki/Wi-Fi
3
http://www.wi-fi.org/discover-and-learn/wi-fi-direct
4
http://fr.wikipedia.org/wiki/Infrarouge

conçu dans le but premier de relier divers équipements sans fils tels les imprimantes, les oreillettes
sans fil, les souris, les claviers, les téléphones portables, les PDA, les GPS, etc., peut être vu comme
une solution future en terme de réduction des coûts dans le domaine de la téléphonie mobile car
intègre plusieurs solutions de communication adaptées à la téléphonie notamment grâce à son profil
de téléphonie sans fil CTP (Cordless Telephony Profil) et biens d’autres. Ceci étant, trois questions
majeures ont retenu notre attention à savoir:
 Premièrement comment utiliser les différentes fonctionnalités du Bluetooth pour proposer une
solution de téléphonie de proximité de bonne qualité et à moindre coût (pour ne pas dire
gratuite) entre deux utilisateurs situés dans un voisinage proche?
 Ensuite, comment briser les barrières posées par la faible portée du Bluetooth pour étendre cette
solution sur une distance de plus de 100 mètre ?
 Et enfin comment adapter cette solution au contexte socio-économique des pays en voie de
développement, afin de pallier au problème de couverture réseau ? (qui relève en générale du
manque de moyens financiers et aussi de volonté de la part des pouvoirs publiques et des
opérateurs de téléphonies qui ne trouvent pas d’intérêt à s’installer ou à déployer leurs
solutions dans des zone à faible densité de population et à faible pouvoir d’achat).
I.3. MOTIVATIONS ET OBJECTIFS
Nos motivations sont nombreuses tout d’abord, la montée en puissance du Bluetooth qui,
bien qu’étant une technologie jeune (1994), gagne de plus en plus du terrain dans le domaine de la
communication sans fils notamment depuis la sortie de sa version 2.0 en 2006 qui a vu son débit
passer de 1 Mb/s à 100 Mb/s. Elle apparaît même comme la technologie WLAN (Wireless Local
Area Network) et WPAN (Wireless personal Area Network) la plus aboutie en matière de gestion de
la Qualité de Service [VAN 07]. En plus de cela, elle opère dans les bandes de fréquences ISM
(Industrial, Scientific and Medical) dont l'exploitation ne nécessite pas de licence et la plupart des
équipements mobiles aux jours d’aujourd’hui sont dotés de puce Bluetooth.
Compte tenu de la situation économique de nos pays (en voie de développement) et compte tenu
du besoin de plus en plus croissant en communication des populations (sur de petites distances
comme au sein d’un campus universitaire, au sein des locaux d’une entreprise, ou simplement entre
deux personnes distantes de moins de 100 mètres) aussi bien dans les pays développés que dans
ceux en voie de développement comme le Cameroun, nous avons jugé nécessaire d’explorer la
possibilité de faire de la téléphonie en utilisant la technologie sans fil Bluetooth. Ceci avec comme
objectif permettre aux utilisateurs des périphériques dont les plates-formes implémentent le
standard Bluetooth, de communiquer librement entre eux par voie ou par texte sans se soucier des
coûts de communication sur des courtes distances et aussi sur des distances plus grandes que la
portée d’un terminal Bluetooth de classe 1 (100mètres).
I.4. LES DOMAINES D’APPLICATIONS DE LA TELEPHONIE PAR

BLUETOOTH
Les propriétés et l’évolution permanente de la technologie Bluetooth en termes de débit

(plus de 100Mbit/s depuis la sortie de sa version 2.0 en 2007), de cout réduit et de la petite taille de
sa puce (9mm de côté pour la plus petite) et de consommation d’énergie, lui permettent de couvrir

plusieurs domaines d’applications en terme de téléphonie. Nous pouvons citer entre autres le
domaine universitaire, médical, entreprise, publicité de proximité, éducation, sécurité de proximité,
I.4.1. Application dans le domaine universitaire

Au sein d’un campus universitaire, on a une grande masse de personnes dans un périmètre
réduit. Et en plus, la plupart des étudiants et enseignants ont un téléphone équipé de Bluetooth.
Ceci dit, on pourrait déployer quelques nœuds routeurs Bluetooth au sein de cet environnement afin
de permettre aux étudiants, aux enseignants et autres personnes d’utiliser aisément notre application
pour communiquer entre eux sur des distances de plus de 100 mètres (grâce aux nœuds routeurs).
Une telle solution réduirait considérablement les couts de communication car deux étudiants
pourraient par exemple se communiquer mutuellement leurs positions sans avoir besoin de passer
par un opérateur téléphonique quelconque.
Aussi avec la situation économique de nos pays, le manque d’infrastructures dans les campus
universitaires rend les amphithéâtres souvent bondés de monde lors des cours en troncs commun 1.
Dans de telles situations, ceux des étudiants qui n’auront pas pu trouver de place à l’intérieur
pourront écouter et même participer au cours à travers leur téléphone connecté à celui d’un autre
étudiant se trouvant à l’intérieur. Il sera possible dans ce cas d’avoir simultanément 7 connexions
maximum au téléphone d’un étudiant à l’intérieur.
Il pourra aussi servir à faire passer des communiqués importants par texto aux étudiants par des
professeurs. Pour cela, le professeur peut soit laisser la charge au délégué de le diffuser ou soit le
faire personnellement. Les différents départements pourraient réserver des terminaux pour en faire
leur boîte à suggestions ou à requêtes. Ainsi, ces terminaux seront toujours actifs pour que ceux qui
auront des requêtes ou des suggestions quelconques puissent les envoyer par texte au terminal dédié
dont ils connaissent le nom et l’adresse physique Bluetooth (Exemple : 00 :12 :40 :53 :c2 :89).
Une telle solution pourrait aussi bien être implémentée dans les établissements secondaires. En
bref elle contribuera à alléger les couts de communication au sein des institutions scolaires.
I.4.2. Applications dans le domaine de la santé

La téléphonie par Bluetooth pourrait être très utile dans les hôpitaux. Généralement dans certains
centres de santé, le personnel utilise des " bippers" pour contacter des médecins, ou des spécialistes
dans des cas d’urgences. Mais en général, il n’y a pas assez de bippers pour tout le personnel
notamment, les infirmiers, le personnel d’appuis, les garde-malades. Et pourtant la plupart de ces
derniers possède un téléphone portable avec Bluetooth qui pourrait permettre de le contacter à tout
moment lorsqu’il est attendu d’urgence et qu’il se trouve dans l’enseigne ou à proximité de
l’hôpital. Il suffirait pour cela d’installer un ou plusieurs nœuds routeurs Bluetooth dans cet hôpital.
I.4.3. Application dans le domaine administratif et en entreprise

Avec la téléphonie par Bluetooth, on pourrait faciliter les communications interpersonnelles dans
les institutions administratives comme les ministères, les délégations, les services centraux et bien
d’autres services publics. En général dans ces structures les communications internes sont faites via
les réseaux d’opérateurs filaires et les terminaux de communication sont fixes. Avec notre solution,
le personnel pourrait communiquer librement moyennant uniquement les frais d’installation de
quelques amplificateurs Bluetooth pour son déploiement. Il en est de même pour les structures
privées (entreprises) qui au lieu de dépenser des grosses sommes d’argent en termes d’appels
1
Cours pour lesquels plusieurs filaires sont concernées et sont rassemblées dans une même salle.

téléphoniques en interne pourraient tout simplement déployer notre application dans leur structure
afin de minimiser les coûts en matière de téléphonie.
I.4.4. Application dans le domaine de la sécurité de proximité

Certains quartiers pour assurer leur sécurité, créent des groupes d’auto-défense qui passent toute
la nuit à surveiller les allées et venues des gens dans le quartier. Mais dans les quartiers qui ont
plusieurs entrées ou qui sont assez grands, il devient assez difficile pour un groupe d’assurer la
sécurité de tous les habitants ou de tous les bâtiments du quartier en même temps. Ainsi avec notre
solution (téléphonie par Bluetooth), tout habitant pourrait contacter le groupe d’auto défense en cas
d’agression ou d’incident quelconque même s’il n’a pas assez d’unité (crédit de communication)
pour passer un appel via le réseau de l’un des opérateurs GSM.
I.4.5. Application dans le domaine de la publicité

C’est beaucoup plus le volet SMS de notre application qui jouera ce rôle. Elle est en générale
appelée « Bluetooth marketing » c’est une application Bluetooth qui permet de diffuser des
contenus multimédias (son, image, diaporama, vidéo) aux appareils Bluetooth environnants. De
même notre application pourra servir à diffuser des SMS dans un voisinage proche. Par exemple un
supermarché en pleine promotion pourrait faire la publicité de ses produits en utilisant notre
solution pour diffuser des SMS et aussi des contenus multimédias à toute personne ayant un
téléphone Bluetooth et se trouvant à portée du terminal de diffusion.
I.5. BILAN
Le déploiement d’une solution de téléphonie par Bluetooth peut être un bon facteur de réduction
des couts de communication dans différents domaines. Les solutions existantes ne sont pas pour
ainsi dire à mettre à l’écart ou à éliminer complètement. Chacune de ces solutions a sa particularité.
Des solutions comme le GSM, malgré le fait qu’elles soient coûteuses, sont incontournables pour le
moment. En plus d’être un chalenge, nous avons opté pour le Bluetooth vue les différents avantages
qu’elle offre et vue son expansion dans la plupart des périphériques à travers le monde. En plus de
cela, le Bluetooth est mieux adapté au contexte socio-économique des pays en voie de
développement où les téléphones dotés de wifi ou de wifi direct ne sont pas très rependus. Le
Bluetooth étant limité par la portée, notre solution visera en plus de permettre la communication
vocale via Bluetooth, de briser ces limites avec l’architecture que nous allons proposer.
I.6. STRUCTURE DU MEMOIRE
Pour mener à bien nos travaux et afin d’atteindre nos objectifs, nous articulerons notre travail
ainsi qu’il suit :
 Dans le 0 qui constitue l’introduction générale, il était question de montrer l’intérêt de faire de
la téléphonie par Bluetooth. Ceci en rappelant le contexte, les applications, la problématique,
les approches connues avec leur inadéquation, notre approche et enfin nos motivations et nos
objectifs.
 Dans le chapitre 2 nous ferons un état de l'art c'est-à-dire nous présenterons les insuffisances des
approches et/ou des modèles connus avec leurs insuffisances par rapport au problème à
résoudre.

 Le chapitre 3 pour sa part présentera de façon plus explicite la solution proposée. Ceci en faisant
une analyse des contraintes particulières (technologiques, applicatives, généricité) liées au
problème spécifique que nous voulons résoudre et en présentant l’approche le modèle et
l’architecture de la plate-forme avec analyse des propriétés. En faisant une étude de la
complexité et des performances avec comparaison aux solutions connues. On fera aussi une
étude des enjeux économiques de la solution.
 Le chapitre 4 concerne la mise en œuvre de la solution. Elle consiste en la présentation de la
plate-forme logicielle qu’on aura développée ainsi qu’en la présentation des résultats des
différentes simulations qu’on aura eu à effectuer.
 Dans le chapitre 5 nous procèderons à la validation de la solution par les différents protocoles
qui auront été définis.

CHAPITRE II. ETAT DE L’ART

Nous allons dans cette partie faire le tour des solutions de réseaux sans fils qui existent (le
GSM, le Wi-Fi, le Wi-Fi Direct, l’infrarouge), donner certaines de leurs applications à la téléphonie
sans fil et en dégager leurs limites afin de montrer en quoi elles sont moins adaptées par rapport à la
solution utilisant le Bluetooth que nous avons adoptée. En plus, nous ferons le tour des solutions de
téléphonie de proximité faites à base du Bluetooth et nous montrerons en quoi notre solution est
meilleure par rapport à notre contexte.
II.1. LE GSM
II.1.1. Description
Le GSM (Global System for Mobile Communication ou Groupe Spécial Mobile) est un
système de communication cellulaire. Il fait partie des réseaux mobiles les plus répandus dans le
monde surtout en Europe, en Asie, en Afrique et au Moyen-Orient avec plus d’1 milliard
d’abonnées dans le monde depuis 2004 [DJO 10] Il fut mis au point en 1982 par la Conférence
européenne des administrations des postes et télécommunications (CEPT).
Le GSM est un réseau commuté ainsi, les ressources ne sont allouées que pour la durée de la
conversation, comme lors de l'utilisation de lignes téléphoniques fixes. Il est basé sur la méthode
d’accès F-TDMA (Frequency Time Division Multiple Access) et utilise deux plages de fréquences
différentes. La première est réservée pour les communications des mobiles vers les stations de base
(890-915 MHz et 1710-1785 MHz pour le GSM 1800) et la deuxième dans le sens des stations de
base vers les mobiles (935-960 MHz et 1805-1880 MHz pour le GSM 1800 [DJO 10] Le
déploiement d’une solution GSM nécessite un ensemble d’équipements de base:
 Le BTS (Base Transceiver Station) : c’est un émetteur-récepteur gérant une cellule. Il gère la
couche physique sur la voie radio : modulation, démodulation, CRC (contrôle de redondance
cyclique), multiplexage, saut de fréquence, chiffrage-déchiffrage des données. Il gère également
la couche liaison de donnée avec le mobile.
 Le BSC (Base Station Controller) : c’est un commutateur qui réalise une première concentration
de circuit. S'occupe de la gestion de la ressource radio (allocation des canaux de
communication).
 Le MSC (Mobile-services Switching Center) : c’est un commutateur pour des entités mobiles. Il
gère l'établissement de circuits de communication à travers le réseau, les SMS et l'exécution du
hand-over. Certains MSC peuvent être des GMSC (Gateway MSC), et servent alors de
passerelle avec un autre réseau de téléphonie.
 Le HLR (Home Location Register) base de données centralisant les informations d'identification
et de localisation de chaque abonné local du réseau.
 Le VLR (Visitor Location Register) base de données agissant à la fois comme un tampon évitant
des accès trop fréquent au HLR. Généralement placé à proximité d'un MSC (souvent dans le
même équipement). Ces bases de données contiennent les données des abonnés présents dans
une zone géographique de façon permanente ou temporaire [MAR 01].

II.1.2. Les services offerts par le GSM

Le GSM a été initialement conçu pour la téléphonie mobile sans fil mais avec son évolution au
fils des années, il propose plusieurs autres services de communication tels que :
 le transfert de donné (le WAP, le Fax ou bien comme un modem filaire classique) à faible
débit (14.4 Kbits/s de base) [BAD 06].
 des services de messagerie courts (SMS) ainsi que leur successeur, le MMS (MultiMedia
Messaging Service),
 le Cell Broadcast (diffusion dans les cellules), qui permet d'envoyer le même SMS à tous les
abonnés à l'intérieur d'une zone géographique et d’autres services supplémentaires (renvois
d'appels, présentation du numéro, etc.).
 les services à valeur ajoutée comme par exemple les services de localisation, les services
d'information à la demande (météo, horoscope), de banque (consultation de compte,
recharges de compte prépayées).
II.1.3. Les limites du GSM

Le déploiement d’une solution GSM n’est pas toujours aisé car cela nécessite de gros
investissements allant du matériel (BTS, BSC, MSC, HLR, VLR) à la mise en œuvre (fabrication
des cartes SIM). Il nécessite aussi la location d’une bande de fréquence car elle n’utilise pas les
bandes ISM (Industrial, Scientific and Medical) comme le Wi-Fi ou le Bluetooth. D’après les
études menées par Delmas et julien dans le livre Les relais GSM [DEL 06] la mise en œuvre d’une
solution GSM est évaluée à plus de 160 000 Euro. Ce qui nous montre que ce standard n’est pas
l’idéale pour une solution de téléphonie de proximité dont l’un des principaux objectifs est de
réduire les coûts de déploiement et de communication.
II.2. LE WI-FI: WIRELESS FIDELITY
Ici, nous allons d’abord décrire brièvement la technologie Wi-Fi, ensuite, nous allons donner ses
applications dans le domaine de la téléphonie et enfin les limites de cette technologie par rapport à
notre approche.
II.2.1. Description du Wi-Fi

Le Wi-Fi est le nom commercial de la norme IEEE 802.11 qui est un standard de réseau sans
fil local définit par le consortium IEEE en juillet 1997. C’est une marque déposée par WECA
(Wireless Ethernet Compatibility Alliance). Le Wifi Utilise une onde porteuse sur laquelle est
modulé le signal à transmettre. Au départ, son débit était de 1 à 2 Mbit/s, mais elle a
considérablement évolué au fil des ans avec les diverses versions qui sont nées entre temps.
II.2.1.1. Les différentes normes du Wi-Fi

Des révisions ont été apportées à cette norme pour améliorer le débit, la sécurité de transmission
et l’interopérabilité. Ce qui a conduit à la création de plusieurs versions de cette norme :
 IEEE 802.11a : La norme IEEE 802.11a (baptisé Wi-Fi 5) permet d'obtenir un haut débit (54
Mbps théoriques, 30 Mbps réels). La norme IEEE 802.11a spécifie 8 canaux radio dans la
bande de fréquence des 5GHz [IEEa 99].
 IEEE 802.11b (Wi-Fi) : La norme IEEE 802.11b est la norme la plus répandue actuellement.
Elle propose un débit théorique de 11 Mbps (6 Mbps réels) avec une portée pouvant aller

jusqu'à 300 mètres dans un environnement dégagé. La plage de fréquence utilisée est la
bande des 2.4 GHz, avec 3 canaux radio disponibles. [IEEb 99]
 IEEE 802.11c : cette norme est en fait un pontage de la norme IEEE 802.11 vers la norme
IEEE 802.1d. Elle n'a pas d'intérêt pour le grand public. Il s'agit uniquement d'une
modification de la norme IEEE 802.1d afin de pouvoir établir un pont avec les trames IEEE
802.11 (niveau liaison de données). [IEEd 04]
 IEEE 802.11d : (Internationalisation) son but est de permettre une utilisation internationale
des réseaux locaux IEEE 802.11. Elle consiste à permettre aux différents équipements
d'échanger des informations sur les plages de fréquence et d’utiliser les puissances de
transmission autorisées dans le pays d'origine du matériel [IEEd 01].
 IEEE 802.11e (Amélioration de la qualité de service) : elle vise à améliorer la qualité de
service au niveau de la couche liaison de données. Ainsi cette norme a pour but de définir
les besoins des différents paquets en termes de bande passante et de délai de transmission de
façon à permettre notamment une meilleure transmission de la voix et de la vidéo [IEEe 05].
 IEEE 802.11f (Itinérance ou roaming en Anglais): La norme IEEE 802.11f [IEEf 03] est une
recommandation à l'intention des vendeurs de point d'accès pour une meilleure
interopérabilité des produits. Elle propose le protocole Inter-Access point (roaming
protocol) permettant à un utilisateur de changer de point d'accès de façon transparente lors
d'un déplacement, quelques soient les marques des points d'accès présentes dans
l'infrastructure réseau.
 IEEE 802.11g : cette norme offre un haut débit (54 Mbps théoriques, 30 Mbps réels) sur la
bande de fréquence des 2.4 GHz. La norme IEEE 802.11g [IEEg 03] a une compatibilité
ascendante avec la norme IEEE 802.11b, ce qui signifie que des matériels conformes à la
norme IEEE 802.11g peuvent fonctionner en IEEE 802.11b.
 IEEE 802.11h : cette norme vise à rapprocher la norme IEEE 802.11 du standard Européen
(HiperLAN2, d’où le "h" de IEEE 802.11h) et être en conformité avec la réglementation
européenne en matière de fréquence et d'économie d'énergie. [IEEh 03]
 IEEE 802.11i [IEEi 04]: cette norme a pour but d'améliorer la sécurité des transmissions
(gestion et distribution des clés, chiffrement et authentification). Elle s'appuie sur le
protocole de sécurité AES (Advanced Encryption Standard) et propose un chiffrement des
communications pour les transmissions utilisant les technologies IEEE 802.11a, IEEE
802.11b et IEEE 802.11g.
 IEEE 802.11Ir : elle a été élaborée pour utiliser les signaux infra-rouges. Cette norme est
désormais dépassée techniquement.
 IEEE 802.11j : c’est à la réglementation japonaise de la norme IEEE 802.11 un peu comme
la norme IEEE 802.11h qui est à la réglementation européenne [IEEj 04].
 IEEE 802.11k : Permet l’optimisation d’allocation des ressources du réseau sans fil selon la
qualité de chaque liaison [IEEk 08].
 IEEE 802.11n: WWiSE (World-Wide Spectrum Efficiency). La norme IEEE 802.11n est
disponible depuis le 11 septembre 2009. Le débit théorique atteint les 300 Mbit/s (débit réel
de 100 Mbit/s dans un rayon de 100 mètres) grâce aux technologies MIMO (Multiple-Input
Multiple-Output) et OFDM (Orthogonal Frequency Division Multiplexing). En avril 2006,

des périphériques à la norme IEEE 802.11n commencent à apparaître basés sur le Draft 1.01.
Des équipements qualifiés de « pré-N » sont disponibles depuis 2006 : ce sont des
équipements qui mettent en œuvre une technique MIMO d'une façon propriétaire, sans
rapport avec la norme IEEE 802.11n. La norme IEEE 802.11n a été conçu pour pouvoir
utiliser les fréquences 2,4 GHz ou 5 GHz. Les premiers adaptateurs IEEE 802.11n
actuellement disponibles sont généralement simple-bande à 2,4 GHz, mais des adaptateurs
double-bande (2,4 GHz ou 5 GHz, au choix) ou même double-radio (2,4 GHz et 5 GHz
simultanément) sont également disponibles. Le IEEE 802.11n saura combiner jusqu’à 8
canaux non superposés, ce qui permettra en théorie d'atteindre une capacité totale effective
de presque un gigabit par seconde. [IEEn 09]
 IEEE 802.11s : (Réseau Maillé) : elle est actuellement en cours d’élaboration. Le débit
théorique atteint aujourd’hui 10 à 20 Mbit/s. Elle vise à implémenter la mobilité sur les
réseaux de type Ad-Hoc. Tout point qui reçoit le signal est capable de le retransmettre. Elle
constitue ainsi une toile au-dessus du réseau existant. Un des protocoles utilisé pour mettre
en œuvre son routage est OLSR. [JOS 06], [WST 12].
 IEEE 802.11u2 : Cette norme a été adoptée le 25 février 2011. Elle vise à faciliter la
reconnaissance et la sélection de réseaux, le transfert d'informations en provenance de
réseaux externes, en vue de permettre l'interopérabilité entre différents fournisseurs de
services payants ou avec des hot-spots 2.0. Elle définit aussi des normes en termes d'accès à
des services d'urgence. À terme, elle doit entre-autres faciliter le délestage des réseaux 3G
de téléphonie mobile.
 k IEEE 802.11v : cette norme a été adoptée le 2 février 2011. Elle décrit des normes de
gestion des terminaux en réseau: (reporting) gestion des canaux, gestion des conflits et
interférence, service de filtrage du trafic.
II.2.1.2. Les modes de fonctionnement du Wi-Fi

 Le mode infrastructure : ce mode de fonctionnement permet de connecter les ordinateurs
équipés d’une carte Wi-Fi entre eux via un ou plusieurs Point d’accès (PA) qui agissent
comme des concentrateurs. Le réseau est alors formé de plusieurs ensembles de services de
base (BSS : Basic Service Set) qui forment ensemble un unique EBSS (Extended Basic
Service Set).
Figure 1 : Le mode infrastructure wifi
1
Le Draft 2.0 est sorti en mars 2007, les périphériques basés sur ce brouillon seraient compatibles avec la version
finale du standard 802.11n.
2
http://en.wikipedia.org/wiki/IEEE_802.11u

 Le mode Ad Hoc : il permet de connecter directement les terminaux équipés d’une carte
Wi-Fi, sans utiliser un matériel tiers tel qu’un point d’accès. Ce mode est idéal pour
interconnecter rapidement des machines entre elles sans matériel supplémentaire. Le réseau
formé est appelé IBSS (Independent Basic Service Set).
Figure 2 : Le mode de fonctionnement Ad Hoc du Wi-Fi
 Le mode pont (Bridge) : ceci est généralement adapté aux points d’accès car il sert à
connecter un ou plusieurs points d'accès entre eux pour étendre un réseau, par exemple entre
deux bâtiments. La connexion se fait au niveau de la couche 2 du modèle OSI. Un point
d'accès doit fonctionner en mode racine « root bridge » et les autres s'y connectent en mode
« bridge » pour ensuite retransmettre la connexion sur leur interface Ethernet. Chacun de ces
points d'accès peut éventuellement être configuré en mode pont avec connexion de clients.
Ce mode permet de faire un pont tout en accueillant des clients comme le mode
infrastructure.
 Le mode répéteur (range-extender) Un point d'accès en mode

Figure 3: répéteur
wifi
répéteur permet de répéter un signal Wi-Fi plus loin (par exemple

pour atteindre un fond de couloir en L). il existe des équipements
wifi spécialisés pour ça comme le répéteur NETGEAR -
WN3000RP (www) 1
II.2.1.3. Les équipements Wi-Fi

Les principaux équipements qui interviennent dans la technologie Wi-Fi sont les suivants :
 Les stations :
Les stations sont équipées d’une carte réseau sans fil (network interface controller ou
Wireless adapter) disponible sous-différents formats (PCI, USB, PCMCIA …). Comme
exemple de station, nous pouvons citer les ordinateurs, les PDA, les téléphones portables
etc.
 Les points d’accès :
Ce sont de concentrateurs pouvant supporter quelques dizaines de connexions sans fils de
débit pouvant aller jusqu’à 11 ou 54 Mbps dans la bande passante de 2,4 GHz, la connexion
au réseau filaire se fait via un port 10 base T ou 100 base T. Ils permettent de faire
communiquer les terminaux entre eux
1
http://www.netgear.fr/home/products/wireless-range-extenders/wireless-range-extenders/WN3000RP.aspx,
http://www.netgear.fr/images/WN3000RP_fr65-17219.pdf

Figure 4 : Exemples de points d’accès Wi-Fi
II.2.2. Application du Wi-Fi liée à la téléphonie : La VoIP

Elle est encore appelée communément VoFi. La VoIP (Voice Over Internet Protocol) est une
technologie qui date des années 70. Elle offre la possibilité de transporter de la voix sur des réseaux
IP. Les premiers travaux furent menés en 1972 par Robert E. Kahn 1 et son groupe la NSC (Network
Secure Communications) formé pour explorer la possibilité de transmission des paquets de données
contenant des échantillons de voix sur le réseau ARPANET2 de façon sécurisé [SST 06a]. Ce qui
donna naissance en Décembre 1973 au protocole NVP 3 (Network voice protocole) qui fut le
pionnier en matière de communication vocale sur les réseaux ARPANET. Bien des années plus tard
en 1995, une petite compagnie israélienne nommée « Vocaltec4 » créer en 1989 par Alan Cohen5
lance le premier logiciel de téléphonie par internet [CHI 08]. Ce logiciel était conçu à la base pour
permettre une communication entre deux PC équipés chacun d'une carte son, d’un microphone et
d’un écouteur. La VoIP a évolué au fil des années, au point qu'en 1998, plusieurs compagnies
proposaient déjà des services de téléphonie de PC à téléphone fixe [SST 06b]. L'envolée de la VoIP
arriva lorsque les grands fabricants tels que Cisco Systems et Nortel proposèrent des équipements
spécifiques VoIP permettant la commutation (plus besoin de passer forcement par un ordinateur)
[ROB 05]. La VoFi (VoIP sur Wi-Fi) est tout simplement l’équivalent de la VoIP dans un réseau
Wi-Fi.
Néanmoins, cette technologie est peu adaptée à la solution de téléphonie que nous voulons
proposer car elle nécessite que l’utilisateur soit connecté à internet pour pouvoir effectuer des
appels. En plus de cela, vue qu’elle est basée sur la technologie Wi-Fi, elle aura forcement les
même limites que celles présentées plus haut à savoir la consommation d’énergies, l’encombrement
de la puce Wi-Fi et bien d’autres. En plus de cela, les utilisateurs auron besoin de téléphone
spécialisés pour cela. Un exemple de téléphone spécialisé dans la VoIp est Le téléphone IP sans fil
G WIP330 de Linksys [SYS 10] qui offre un service de téléphonie sur IP (VoIP) de haute qualité
via un réseau sans fil G basé sur les normes IEEE 802.11b, IEEE 802.11g du Wi-Fi et une
connexion Internet haut débit [SYS 10].
II.2.3. Les limites du Wi-Fi

Malgré les nombreux atouts offerts par la technologie Wi-Fi, elle n’est pas adaptée aux
téléphones portables à cause de l’encombrement et sa forte consommation d’énergie de sa puce qui
résulte de son débit élevé (plus de 54Mbps). En plus de cela, les téléphones intégrant le Wi-Fi ne
sont pas à la portée de toutes les bourses dans les pays en voie de développement.
II.3. LE WI-FI DIRECT
C’est une nouvelle norme de la Wi-Fi Alliance [WIF 10] qui a pour but d’offrir la possibilité
aux équipements Wi-Fi de communiquer en paire à paire de façon réelle, sans avoir besoin de
1
Bob Kahn pionnier dans le développement du protocole TCP-IP, http://en.wikipedia.org/wiki/Bob_Kahn
2
ARPANET (Advanced Research Projects Agency Network) est le premier réseau à transfert de paquets développé
aux États-Unis. Il deviendra la base du transfert de données sur Internet : http://fr.wikipedia.org/wiki/ARPANET
3
http://www.rfc-ref.org/RFC-TEXTS/741/index.html
4
http://en.wikipedia.org/wiki/VocalTec#cite_note-Tov-0
5
http://en.wikipedia.org/wiki/Alon_Cohen

passer par un point d’accès. En réalité le Wi-Fi supporte les connexions en mode ad-hoc entre deux
équipements mais le Wi-Fi Direct permet de se passer des tâches de configuration qui s’avèrent très
souvent difficiles pour les non-initiés1. Ceci facilite la communication entre périphériques tel que :
les appareils numériques, les scanner, les imprimantes, un peu comme les connections USB. Le
Wi-Fi direct est totalement compatible avec le Wi-Fi classique. Il fonctionne pratiquement de la
même manière que le Bluetooth à la différence que le Wi-Fi Direct qui a hérité des propriétés du
Wi-Fi classique qui surpasse le Bluetooth en termes de portée, de bande passante et de débit [NEI
10].
A ce jour on ne dénombre encore aucune application téléphonique faite à base du Wi-Fi direct.
Car même s’il est vrai qu’elle a beaucoup d’atouts, cette technologie est encore très jeune (2009)
donc pas encore tout à fait au point et son intégration dans les téléphones mobiles n’est pas encore
totalement aboutie. Ceci étant, il n’est intégré que dans très peu de téléphones mobiles de nos jours
parmi lesquels la Samsung Galaxy S qui fut le premier téléphone mobile à recevoir la certification
Wi-Fi Direct en novembre 2010 [PIN 11]. En plus tout comme le Wi-Fi, le Wi-Fi Direct est limité
par la surconsommation en énergie et son coût très levé.
II.4. L’INFRAROUGE
La technologie infrarouge permet de relier deux dispositifs dotés de ports à infrarouge. Les
infrarouges sont des rayonnements électromagnétiques invisibles, de longueur d'onde comprise
entre 0,8 µm2 (lumière rouge visible) et 1 mm (micro-ondes). Les radiations infrarouges furent
découvertes en 1800 par l'astronome anglais William Herschel3, qui constata, en étudiant le spectre
solaire, l'existence d'un échauffement notable dans une zone située en deçà du rouge.
Les rayons à infrarouge ont plusieurs applications dans le domaine de la communication sans fils
 La domotique (télécommande à distance) : c’est l’une de ses applications

parmi lesquels :
les plus courantes. Ils sont préférés aux ondes radio, car ils n'interfèrent pas
avec les autres signaux électromagnétiques comme les signaux de
 La robotique : contrôle des robots à distance

télévision ;
Figure 5 : télécommande à infrarouge
 Applications militaires pour le guidage des missiles air-air ou anti-aériens

 Les infrarouges sont aussi utilisés pour la communication à courte distance entre les ordinateurs
et leurs périphériques. Les appareils utilisant ce type de communication sont généralement
conformes aux standards IrDA4 (Infrared Device Association).
Même s’il est vrai que l'infrarouge présente plusieurs applications dans le domaine de la
communication il faut dire qu’il a aussi beaucoup de limites et d’inconvénients. Le principal
inconvénient de l’infrarouge est qu’il ne permet pas la communication entre deux équipements non
directement visibles. Car les infrarouges ne peuvent passer à travers les objets. L'IrDA présente
aussi deux inconvénients majeurs : un temps de réaction très lent et l'obligation de maintenir
l'émetteur dans le faisceau de réception sans obstacle en chemin. Ce problème est très important
notamment pour les applications audio-vidéos qui ne peuvent pas supporter les coupures dans la
transmission des données, même sur de très courtes distances.
1
Ceux qui ne sont pas habitués ou qui n’ont jamais fait une configuration Wi-Fi en mode ad-hoc
2
µm : micromètre
3
Herschel, sir William (1738-1822), astronome anglais d'origine allemande, fondateur de l'astronomie stellaire. (
[ENC 09]]
4
IrDA : Infrared Device Association : organisation fondé en 1993 pour promouvoir les standards de communication
point à point basés sur Infrarouge.

II.5. LE BLUETOOTH
II.5.1. Historique
Le Bluetooth fut créé en 1994 par le fabricant suédois Ericsson. En 1998, plusieurs grandes
sociétés dont IBM, Intel, Nokia et Toshiba s'associent à Ericsson pour former le Bluetooth Special
Interest Group (SIG). En juillet 1999, sortie de la spécification 1.0. Le SIG compte 9 membres en
décembre 1999 après que les entreprises 3COM, Lucent, Microsoft, Motorola les a rejoint. Le 28
mars 2006, le SIG annonce la deuxième génération de la technique sans fil Bluetooth, qui est
capable d'assurer des débits cent fois supérieurs à l'ancienne version, passant donc de 1 Mb/s à 100
Mb/s (soit 12,5 Mo/s)1. Cette technique, utilisée dans les téléphones mobiles, périphériques
informatiques et autres appareils portables comme les assistants personnels (PDA) a vu sa vitesse de
transmission augmenter année après année, lui permettant ainsi d'être utilisée pour les vidéos hautes
définitions et l'échange de fichiers avec un baladeur MP3 par exemple.
Le terme « Bluetooth » fut inspiré par le nom d’un roi danois du 10éme siècle entre les années 940
et 981 appelé « Harald Ier» et surnommé par son peuple « Harald Blåtand » (qui voulait dire
homme à la dent bleue). Il fut connu pour avoir réussi à unifier les États du Danemark, de Norvège
et de Suède. Le logo2 de Bluetooth, est d'ailleurs inspiré des initiales de Harald (H : ) et Blåtand
(B: ) en alphabet runique3. [VAL 07]
II.5.2. Les différentes normes Bluetooth

 IEEE 802.15.1 définit le standard Bluetooth 1.x permettant d'obtenir un débit de 1Mbit/s ;
 IEEE 802.15.2 propose des recommandations pour l'utilisation de la bande de fréquence 2,4
 IEEE 802.15.3 est un standard qui permet d’avoir le haut débit avec la technologie Bluetooth. Il
GHz (fréquence utilisée également par le Wi-Fi). Ce standard n'est toutefois pas encore validé ;
définit la norme UWB (Ultra-Wide Band), qui met en œuvre une technologie très spéciale,
caractérisée par l’émission à une puissance extrêmement faible. Les débits atteints sont de l’ordre
 IEEE 802.15.4 est un standard en cours de développement pour des applications sans fils à bas
du gigabit par seconde sur une distance de 10 mètres [GUY 06].
débit et à faibles coûts. Il est actuellement utilisé par Zigbee pour ses couches basses.
II.5.3. La pile de protocole Bluetooth

Le Bluetooth utilise une architecture en couche pour le transport des données comme dans la
plupart des réseaux. La pile de protocole Bluetooth comprend une partie matérielle et une partie
logicielle telles que présentées dans la figure ci-dessous.
Les deux couches les plus basses de la partie matérielle (couche radio et couche bande de base)
sont les deux principaux composants d’un produit Bluetooth. Ce sont ces éléments qui rendent
possible les communications sans fils entre deux équipements Bluetooth même s’il est vrai que les
autres couches sont toutes aussi nécessaires qu'indispensables. Dans la suite de notre travail, nous
ferons une description explicite de chaque composant de cette pile, ceci en présentant d’abord les
1
http://fr.wikipedia.org/wiki/Bluetooth
2
Logo Bluetooth
3
Alphabet runique : Le plus récent futhark (ou alphabet runique) nordique à 16 runes (caractère alphabétique dont
se servaient les anciens scandinaves) :

éléments de la couche physique ensuite ceux de la couche applicative en passant par le HCI (Host
Control Interface) qui fait le lien entre les deux couches.
Figure 6 : La pile de protocole Bluetooth
II.5.3.1. Présentation de la couche matérielle
II.5.3.1.1. Couche Radio Fréquence (RF):

C’est la couche la plus basse de la pile de protocole Bluetooth. C'est elle qui s'occupe de
l'émission et de la réception des ondes radio. Elle définit les caractéristiques telles que : celles de la
bande de fréquence et l'arrangement des canaux, celles de l’émetteur, du récepteur du signal et de la
modulation. La technologie Bluetooth compte 3 classes d’émetteur :
Table 1: Les différentes classes d'émetteurs Bluetooth
Classe puissance portée

1 100mW 100 mètres
2 2.5mW 15 à 20 mètres
3 1mW 10 mètres.
La plupart des
constructeurs du SIG d’appareils électroniques préfèrent utiliser la classe3 [PAS 05] cause de sa
faible consommation d’énergie. Du coup, c’est cette classe qui est la plus rependue et la plus
utilisée dans les périphériques mobiles. La technologie Bluetooth utilise une bande de fréquence qui
s’étend sur 83.5MHz (entre 2402 et 2480 MHz) et divisée en 79 canaux numérotés de 0 à 78 avec
chacun une largeur de 1 MHz. Ce sont des bandes de fréquences de type ISM1 (Industrial,
Scientific & Medical). Le canal d’émission est divisé en slots2 de 625µs. Comme le Wi-Fi, le
Bluetooth utilise la technique FHSS3 (Frequency Hope Spread Spectrum), pour la transmission des
données en utilisant une combinaison de saut de fréquence différent pour permettre à plusieurs
terminaux d’émettre simultanément. Cette technique (le FHSS) a pour rôle principale de permettre
une synchronisation parfaite entre l’émetteur et le récepteur et d’éviter les interférences du fait de la
saturation de la bande de fréquence ISM.
1
Les bandes de fréquence ISM sont réservées pour l'industrie, la science et la médecine et leur utilisation et
gratuite.
2
Slot : intervalle de temps nécessaire pour qu’une trame se propage en aller/retour, entre les deux extrémités d’un
support de transmission. Après ce délai, la station émettrice peut être assurée que sa trame n'a pas été collisionné
3
FHSS : Etalement de spectre par saut ou évasion de fréquence. Ou plus simplement, c’est une technique de saut de
fréquence suivant un séquence pseudo aléatoire déterminé par le maitre dans un piconet. [RAB 04]

II.5.3.1.2. La couche bande base (Baseband)

Le rôle principal de cette couche et de transmettre au module radio les données qui seront
envoyées. Il encapsule les données provenant de la couche supérieure dans un paquet selon le
format des paquets de données selon la norme Bluetooth. C’est au niveau de cette couche que sont
définies les adresses matérielles des périphériques (équivalent à l'adresse MAC d'une carte réseau).
Cette adresse est nommée BD_ADDR (Bluetooth Device Address) et est codée sur 48 bits. C'est
également la bande de base qui gère les différents types de communication entre les appareils. Les
connexions établies entre deux appareils Bluetooth peuvent être synchrones ou asynchrones. La
bande de base peut donc gérer deux types de paquets : dont les paquets SCO (Synchronous
Connection-Orientated) utilisés principalement pour la voix et les paquets ACL (Asynchronous
Connection-Less) utilisés pour les autres types de données.
II.5.3.1.3. Le contrôleur de liaison (Link Controller)

Elle gère la configuration et le contrôle de la liaison physique entre deux appareils. Son rôle
principal est de demander à la couche inférieure (Baseband) de construire les paquets, afin d'établir
et de maintenir une ligne de transmission fiable.
II.5.3.1.4. Le gestionnaire de liaison (LMP: Link Manager Protocol)
Cette couche gère les liaisons entre les périphériques Bluetooth maître et l’esclave. Elle gère
aussi le type de connexion (SCO ou ACL) utilisé pour la communication. C’est elle qui implémente
les mécanismes de sécurité comme : L'authentification, le pairage, la création et la modification des
clés, et le cryptage.
II.5.3.1.5. L’interface de contrôle (HCI : Host Controller Interface)

Cette couche fourni une interface uniforme pour l’accès à la couche matérielle. Elle joue
aussi un rôle de séparation qui permet une liberté et une indépendance dans leur développement des
parties matériel et logiciel. Il supporte les protocoles de transports suivants : Universal Serial Bus
(USB) ; PC-Card ; RS-232 et UART.
II.5.3.2. Présentation de la couche applicative
II.5.3.2.1. La couche L2CAP (Logical Link Control & Adaptation Protocol)

Cette couche permet d'utiliser simultanément différents protocoles de niveaux supérieurs. La
couche L2CAP gère également la segmentation (et le réassemblage) des paquets de protocoles de
niveaux supérieurs en paquets de liaison de 64 Ko. Elle fournit aussi les services de multiplexage
aux protocoles de niveaux supérieurs, pour cela, un mécanisme permet d'identifier le protocole de
chaque paquet envoyé pour permettre à l'appareil distant de passer le paquet au bon protocole, une
fois celui-ci récupéré. [FAB 11]. L2CAP fourni deux type de canaux de communication: les canaux
orientés non connexion est ceux orientés connexions qu’il ne faut pas confondre aux liaisons SCO
(Synchronous Connection, Oriented). Pour les canaux orientés non connexions, les communications
ne vont que dans un seul sens d’un maître à un groupe de périphérique esclave. Elles sont
généralement utilisées pour les phases de pairage et d’authentification. Pour ce qui est des canaux
orientés connexion, elles sont utilisées entre un maître et un esclave pour un échange de données
synchrones comme la voix.
II.5.3.2.2. Les services Bluetooth

 RFCOMM : est un service basé sur les spécifications RS-232, qui émule des liaisons séries.
Il peut supporter plus de 60 communications simultanées entre deux périphériques

Bluetooth. Par exemple on peut avoir plusieurs applications tournant sur un même
périphérique qui cherchent simultanément à accéder à diverses ressources Bluetooth avec
lequel leur périphérique est connecté. Il peut aussi servir à faire passer une connexion IP par
Bluetooth pour accéder à internet.
 TCS : Telephony Control Protocol Specification Binary
Il s’agit du protocole utilisé pour interagir avec les applications téléphoniques par
l’utilisation des connections L2CAP. Ce protocole définit le contrôle de signalisation d'appel
pour l'établissement des appels vocaux et de données entre appareils Bluetooth. [SIG 01]
 SDP (Service Discovery Protocol). Ce protocole permet à un appareil Bluetooth de
rechercher d'autres appareils et d'identifier les services disponibles. Il définit la manière dont
un client Bluetooth agit pour découvrir les différents services Bluetooth disponibles chez le
serveur et les caractéristiques de ces services [SIG 10a] [GRY 01].
 OBEX (Object Exchange). Ce service permet de transférer des données grâce à OBEX,
protocole d'échange de fichiers IrDA.
II.5.3.2.3. La couche application

Le concept de profil est utilisé afin d’assurer le maximum de compatibilité entre les produits des
différents constructeurs de produits Bluetooth. Ainsi, tous auront les mêmes modèles utilisateurs
dans leur couche logicielle : on aura pour tous les appareils Bluetooth les mêmes appellations pour
chaque fonctionnalité supportée. Les profiles Bluetooth ont donc été développés afin de décrire
comment implémenter les modèles utilisateur. Ils définissent :
- La manière d'implémenter un usage défini ;
- Les protocoles spécifiques à utiliser ;
- Les contraintes et les intervalles de valeurs de ces protocoles.
II.5.3.3. Les profils Bluetooth

Les profiles permettent de faciliter les connexions et d’assurer l’interopérabilité entre les
composants Bluetooth. Ils définissent les couches qui devront être utilisées. Tous les composants
Bluetooth sont obligatoirement placés dans un profil. Il existe 24 profils différents :
1. GAP: Generic Access Profile 12. CTP: Cordless Telephony Profile [SIG
2. SDAP: Service Discovery Application 10a]
Profile 13. IP: Intercom Profile
3. SPP: Serial Port Profile 14. A2DP : Advanced Audio Distribution
4. HS Profile: Headset Profile Profile (profil de distribution audio
5. DUN Profile: Dial-up Networking Profile avancée)
6. LAN Access Profile (Ce profil est 15. AVRCP : Audio Video Remote Control
maintenant obsolète. Il est remplacé par le Profile (Commande à distance)
profil PAN) 16. HFP : Handset Free Profile
7. Fax Profile 17. PAN: Personal Area Network Profile
8. GOEP: Generic Object Exchange Profile 18. VDP: Video Distribution Profile
9. SP: Synchronization Profile 19. BIP: Basic Imaging Profile
10. OPP: Object Push Profile 20. BPP: Basic Printing Profile
11. FTP: File Transfer Profile 21. SYNC: Synchronization Profile
22. SAP: SIM Access Profile

23. PBAP : Phone Book Access Profile 24. HIDP : Human Interface Device Profile.
Il existe une hiérarchie entre profil, et donc des dépendances entre eux. Nous allons illustrer de
façon explicite chacun des profils qui nous intéressent dans la suite.
II.5.3.4. Les différentes topologies de réseaux Bluetooth
II.5.3.4.1. Réseau piconet

Un piconet est un réseau qui se crée de manière instantanée et automatique quand plusieurs
périphériques Bluetooth sont dans un même rayon de portée. Ce réseau suit une topologie en étoile:
1 maître pour plusieurs esclaves. Un périphérique maître peut administrer jusqu'à 7 esclaves actifs
ou 255 esclaves en mode parked (inactif). La communication est directe entre le maître et un
esclave. Les esclaves ne peuvent pas communiquer entre eux. Tous les esclaves du piconet sont
synchronisés sur l'horloge du maître. C'est le maître qui détermine la fréquence de saut de fréquence
pour tout le piconet.
Figure 7 : piconet
II.5.3.4.2. Réseau scatternet

1
Les Scatternets sont en fait des interconnexions de Piconets entre eux. Ces interconnexions sont
possibles car les périphériques esclaves peuvent avoir plusieurs maîtres.
Figure 8 : Scatternet
1
Scatter = dispersion.

II.5.4. Les avantages du Bluetooth par rapport à nos objectifs

En nous situant dans le contexte des pays en voie de développement, les principaux avantages du
Bluetooth sont les suivants :
 son cout qui est relativement très faible environ 20$ ;
Figure 9 : puce Bluetooth (14×36×4 mm)
 sa puce de très petite taille (16mm);

 Sa très faible consommation en énergie électrique ;
 Son évolution constante avec la sortie de la version 4.0 en 2010 qui offre
un débit de plus de 20 Mbit/s [SIG 10a]. Le Bluetooth 4.0 inclut une fonctionnalité d'économie
d'énergie appelé «Bluetooth low energy ». Le Bluetooth 4.0 est en fait trois spécifications
Bluetooth en un seul. il utilise non seulement la nouvelle technologie de faible consommation
d'énergie, mais s'appuie également sur les transferts des données à haute vitesse, introduites
depuis la version 3.0 [SIG 10a]
Néanmoins cette technologie a aussi des limites notamment concernant la sécurité des données
transmises. Mais cette limite est mineure car pour la téléphonie, les données transmises sont en
général sous un format audio.
II.5.5. Les applications téléphoniques liées à la technologie Bluetooth

Les applications que nous avons récences dans ce sens sont en générale destinées à la plateforme
Android.
II.5.5.1. Application de communication Bluetooth sur Android appliqué à la

Samsung Galaxy S.
C’est un projet lancé par la RATP1 et réalisé par Telecom Sud-Paris qui visait à moderniser
les services de télécommunication entre agents RATP et les usagers de leurs services. L’idée était
de permettre à un usager de connecter simplement son téléphone mobile à un point d’accès et
d’accéder au service qui lui permettra d’établir une communication bidirectionnelle avec un agent
RATP sans utiliser le réseau d’un quelconque opérateur GSM.
Cette application fut en partie réalisée par deux élèves ingénieurs le Telecom Sud-Paris qui ont
rencontré beaucoup de problèmes notamment du le fait que le profil Bluetooth PAN (Personal Area
Network) qui permet la connexion entre un terminal et un point d’accès (ou une borne) Bluetooth,
n’était pas encore intégré dans l’api java de développement d’applications Android. Au terme de
leurs travaux, bien qu’ils n’aient pas pu réaliser l’application proprement dite, Leurs multiples
recherches ont permis de montrer que le déploiement de l’application de communication Bluetooth
était théoriquement possible sur la plate-forme Android [GUI 10].
II.5.5.2. Application de type Talkie-Walkie sur terminaux mobiles Android

Cette application permet à plusieurs personnes de communiquer oralement via leur terminal
Android par Bluetooth ou Wi-Fi [BOU 11]. La communication se fait de proche en proche, sans
connexion Internet ni opérateur GSM. L'envoi d'un message vocal est réalisable par pression sur le
bouton push-to-talk ou par détection vocale en utilisant un kit main-libre. Cette application est
destinée à un groupe d'utilisateurs restreint. Chaque utilisateur doit posséder un terminal Android
(version supérieure ou égale à 2.1) sur lequel il devra installer puis lancer l'application.
1
RATP : Régie autonome des transports parisiens, c’est un établissement public français fondé en 1948, qui
exploite le réseau de transport public parisien. Il a été créé en vue de palier aux problèmes de circulations dans la
capitale française. Site officiel http://www.ratp.fr

Il existe aussi plusieurs autres applications de type talkie-walkie sur la plateforme Android
Market1 ou sur Google application2, on peut par exemple citer entre autre : « Virtual-Walkie-
talkie » ou « Znuggler - Walkie-Talkie PTT ». Néanmoins ces applications en dehors du fait
qu’elles ne soient pas open source, sont complètement dédiées à la plateforme Android et limitées à
une utilisations en point à point entre deux utilisateurs distants de moins 10mètres. Par conséquent,
elles ne sont pas adaptées à une utilisation massive ou grand-publique.
II.6. BILAN DU CHAPITRE
Vu que nous voulons faire de la téléphonie de proximité, il serait bénéfique pour nous d’utiliser
un composant qui n’est ni gourmand en énergie ni en espace. Ce qui est bien le cas du Bluetooth qui
consomme très peu d’énergie et dont la puce est relativement très petite et par conséquent peu
gourmande en espace dans l’équipement qui la contient. En plus de cela, contrairement à
l’infrarouge, les équipements Bluetooth n’ont pas besoin d’être en contact visuel pour pouvoir
communiquer [PAS 05]. Le plus impressionnant avec le Bluetooth est surtout son mécanisme
sophistiqué de détection d’équipements et de service, sa capacité à pouvoir établir des connexions
entre périphériques, à effectuer des transferts de fichiers et à gérer la déconnexion sans nécessiter
l’intervention de l’utilisateur [SIN 05]. En faisant le tour des technologies sans fil existantes, le
Wifi-direct est celle qui a le plus attiré notre attention. On pourrait même dire serait la mieux
adaptée du point de vue fonctionnalités pour la solution que nous voulons mettre sur pied. Mais
comme nous avons pu le constaté, elle n’est pas encore complètement abouti est ses applications
sont limité à une poigné de périphériques spécialisés qui ne sont pas à la solde de tout le monde.
1
http://www.android.com/market/, c’est la plateforme proposé Android pour la publication des applications
Android. Elle compte actuellement plus de 2500 publications.
2
http://code.google.com/p/

CHAPITRE III. PRESENTATION DE LA SOLUTION
III.1. INTRODUCTION
Parmi les diverses solutions de téléphonies qui existent de nos jours, on a pu constater qu’elles
ne sont généralement pas adaptées au contexte socio-économique des pays en voie de
développement du fait des contraintes liées aux équipements surpuissants qu’ils demandent pour
leur fonctionnement. Nous allons dans cette partie présenter de façon explicite les divers contours
de notre application en allant de l’analyse des contraintes à l’architecture de la plate-forme en
passant par l’approche et le modèle que nous allons vous présenter.
III.2. ANALYSE DES CONTRAINTES PARTICULIERES LIEES A LA

TELEPHONIE PAR BLUETOOTH.
La mise en place d’une solution de téléphonie de proximité est liée à plusieurs contraintes
notamment : les contraintes technologiques, les contraintes applicatives, en qualité de service
(QoS) et les contraintes de généricité.
III.2.1. Contraintes technologiques

Comme contraintes technologiques nous allons citer entre autre : le support de
communication, la plateforme ou l’environnement de déploiement, la technologie sans fil qui sera
utilisée et les protocoles de communication à utiliser.
Pour ce qui est du support de communication pour notre application, nous pouvons citer entre
autres les téléphones portables et les tablettes tactiles ayant une puce Bluetooth. Mais nous somme
limité par le fait que chacun de ces périphériques est généralement lié à un environnement
particulier (le système d’exploitation) parmi lesquelles : LIMO, Android, IPhone OS, Symbian OS,
Windows mobile ou Windows phone, RIME OS, Palm OS et bien d’autres. Mais nous allons dans
un premier temps baser notre application sur la plateforme Android vue sa montée de plus en plus
croissante dans le monde des systèmes pour Smartphones et tablettes tactiles.
En termes de protocole de communication, vu que nous allons utiliser le Bluetooth comme
technologie sans fil, nous allons naturellement prendre en compte les différents protocoles offerts
par cette technologie qui sont en rapport avec la communication vocale. Nous pouvons citer entre
autre :
 Le protocole de contrôle de téléphonie (TCS Binary) qui définit les signaux de contrôle
d'appel pour l'établissement d'appels voix ou données entre les périphériques Bluetooth.
 le protocole de gestion de liaison (LMP: Link Manager Protocol) qui est responsable de
l'établissement de la connexion entre les équipements Bluetooth. Il se charge de fournir des
outils de sécurité comme l'authentification, le cryptage par génération, échange et
vérification des clés de liaison et de cryptage. Il gère aussi le contrôle et la négociation de la
taille des paquets de bande de base.
 le protocole de recherche de services (SDP)1, comme nous l’avons dit plus haut, ce
protocole définit la manière dont un client Bluetooth agit pour découvrir les différents
1
SDP est la base de la recherche de service sur tous les équipements Bluetooth

services Bluetooth disponibles chez le serveur et les caractéristiques de ces services [SIG
10b] [GRY 01].
 On a aussi le protocole L2CAP (Logical Link Control & Adaptation Protocol) que nous
n’allons pratiquement pas utilisée car il ne gère que les connexions asynchrones ACL.
 RTP (RealTime Transport Protocole) qui fournit de bout en bout des fonctions de réseaux
de transport appropriés pour des applications qui transmettent des données en temps réel,
comme l'audio, la vidéo. [RFC 96]
 RTCP (Real-time Transport Control Protocole) assure le transport temps réel des données et
permet le suivit de leur livraison de manière évolutive [RFC 96]
Nous verrons plus bas dans ce chapitre les différents protocoles de routage et de formation de
scatternet que nous allons utiliser.
III.2.2. Contrainte applicatives et en qualité de service (QoS)

Le but premier de notre travail est de pouvoir transmettre la voix d'un interlocuteur à un autre en
essayant de surpasser la faible portée du Bluetooth. La transmission de la voix se doit d’être
continue et fluide entre deux interlocuteurs (orienté connexion) dans le réseau. Ce qui impose
l’utilisation des paquets SCO (Synchronous Connection-Orientated) qui dans le cas du Bluetooth
sont gérés au niveau de la couche Base band (Band Base) [PAS 05]. Il faut aussi ajouter qu’entre
deux utilisateurs, le délai entre l’envoi et la réception d’un message vocal doit être le plus court
possible. C'est-à-dire la différence entre le temps où un utilisateur parle et le temps où l’autre reçoit
doit être le plus faible possible. Puisque le débit de transmission Bluetooth est limité à 64Kbits/s
pour les communications synchrones [SIG 10c], nous allons assurer la fluidité de la communication
et l’efficacité dans les transmissions de la voix en utilisant un mécanisme de compression audio qui
permettra d’éliminer les informations redondantes1 dans les séquences audio à transmettre avec
pour objectif de réduire considérablement la taille des paquets audio qui vont circuler dans le
réseau d’un périphérique à un autre. En plus, l'application doit être très peu gourmande en énergie,
c’est-à-dire avoir un coût d'utilisation de la batterie le plus faible possible. Ceci parce qu’elle est
sensée fonctionner sur des équipements mobiles avec en général peut d’autonomie2. Cette dernière
contrainte explique une fois de plus notre choix pour la technologie Bluetooth qui consomme très
peu d’énergie électrique. En plus de ces contraintes nous avons les contraintes de généricités qui
doivent aussi être respectées.
III.2.3. Les contraintes de généricité

Notre approche se doit d’être générique, pour pouvoir être facilement adaptable à plusieurs
plateformes de téléphones. Ainsi nous comptons définir un module générique de bas niveau qui sera
commun à plusieurs environnements de téléphonies. Nous avons vu précédemment que la pile de
protocole Bluetooth est divisée en deux principales parties : une partie matérielle et une partie
1
Informations superflues et inutiles.
2
Autonomie : capacité à pouvoir fonctionner sans apport d’énergie supplémentaire.

logicielle. La partie logicielle qui interagit directement avec les applications et services, et la partie
matérielle qui est directement liée à la puce Bluetooth, est commune à toutes les plates-formes.
III.3. APPROCHE ET MODELE DE LA SOLUTION
III.3.1. Présentation de l’approche

Notre approche est simple. Un périphérique pour communiquer avec un autre, va d’abord
vérifier si ce dernier (avec lequel il souhaite communiquer) se trouve dans son voisinage. Si tel est
le cas, un canal de communication synchrone SCO RFCOMM [BLU 03] est créé entre les deux
pour leur permettre de communiquer. Dans le cas contraire, le périphérique initie une demande de
communication au point d’accès (nœud routeur) qu’il aura choisi comme maître. Cette demande
comporte entre autres : ses informations dans le piconet notamment sa BD_ADDR, les informations
sur son horloge, et les informations sur le nœud destinataire. Ce sera donc au nœud routeur de
rechercher le destinataire et la meilleure route pour que les deux nœuds puissent communiquer.
Nous avons ci-dessous un descriptif algorithmique de cette approche. Le premier cas illustre le cas
où les deux périphériques ont le même point d’accès comme nœud routeur et le deuxième montre le
cas où les deux périphériques ne sont pas couverts par le même nœud routeur.
Cas 1 : A et B sont soit à proximité l’un de l’autre, soit couverts par le même nœud routeur
I
A B
I
N. R
N. R=Nœud routeur Bluetooth
Figure 10 : A et B sont couverts par le même nœud routeur
Cas 2 : A et B ne sont pas couverts par le même nœud routeur
A B
R R R R
Figure 11: A et B ne sont pas couverts par le même nœud routeur
Ceci se traduit par l’algorithme suivant :

RouterNode Ra; // nœud router du nœud A

Node A, B; // les deux nœuds qui veulent communiquer
If(isVinicity(A,B)){
createCommunicationChannel (A,B) ;
}else{
sendCommunicationRequest (Ra, A,B) ;
}
// La méthode suivante est une méthode récursive.
Void sendCommunicationRequest(RouterNode R, Node N1, Node N2){
RouterNode R’=nextRouterNode() ;
If (isVinicity(R,N2)) {
createCommunicationChannel(N1,N2) ;
}else {
sendCommunicationRequest(R’, N1,N2) ;
}
}
// la méthode isVinicity(…)
Boolean isVinicity (Node N1, Node N2){
Return vrai si (N1 est voisin de N2);
}
Algorithme 1: création du canal de communication entre deux points A et B qui souhaitent communiquer
Nous allons dans la suite décrire notre solution ainsi que l’ensemble des éléments qui entreront
en jeu dans sa mise en œuvre. Notamment, ce que nous entendons par nœuds routeurs, le protocole
de formation du scatternet et le protocole de routage seront utilisés. Ensuite, nous présenterons
l’architecture graphique de notre solution prenant en compte tous ces éléments. Nous allons d’abord
commencer par présenter les deux cas de communications qu’offre notre solution.
III.3.2. Présentation des deux cas de communications
III.3.2.1. Cas d’une communication en mode point à point

Pour le cas d’une communication en mode point à point, il faudra au préalable créer deux
canaux de communication bidirectionnelles RFCOMM appelés Socket RFCOMM1 [FEN 08]. Le
premier (socket serveur), permettra d’écouter et de gérer les demandes de connexion coté serveur et
le second (socket client) permettra de gérer les communications entre le client et le serveur après
l’établissement de la connexion entre les deux. Lorsque la connexion est établie (i.e. lorsque ce le
périphérique serveur aura accepté la demande de connexion envoyé par le client), il fermera le
socket serveur afin d’empêcher toute autre demande de connexion d’un autre client au cours de leur
communication, car il faut rappeler que nous somme dans le cas d’une communication point à
point. De ce fait nous n’aurons pas besoin de plus de deux périphériques pour communiquer. Nous
avons dans la figure suivante une illustration de ce cas :
1
Pour les échanges de données en streaming (technologie qui permet de diffuser les contenus audio-vidéo en
continue au fur et à mesure du téléchargement) dans le réseau Bluetooth. A ne pas confondre aux sockets TCP qui est
son semblable dans les réseaux internet. On a aussi les sockets L2CAP pour les transfère des data gramme un peu
comme les sockets UDP.

Figure 12: communication P2P entre deux périphériques
Il est vrai que dans la technologie Bluetooth, on distingue les sockets RFCOMM et les sockets
basés sur le protocole OBEX (Object Exchange) [STE 05]. Nous avons choisi les sockets
RFCOMM car ils sont mieux adaptés à la diffusion des contenus multimédia en continu en
occurrence la voix (qui fait l’objet de notre attention) en plus, il est natif à la technologie Bluetooth
contrairement aux sockets basés sur le protocole OBEX.
III.3.2.2. Cas d’une communication passant par un point d’accès Bluetooth.

Pour le cas d’une communication utilisant un ou plusieurs points d’accès Bluetooth nous
présentons dans le schéma suivant un bref aperçu de ce qu’il en ait.
Dans ce schéma, nous avons introduit plusieurs concepts et plusieurs éléments que nous allons
décrire plus en détail dans la suite.
III.3.3. Description du nœud routeur (NR) « point d’accès » Bluetooth

Nous considérons un nœud routeur tout simplement comme un périphérique Bluetooth de classe
1. De façon plus soutenue dans notre modèle, un nœud routeur est en fait un ensemble de plusieurs
périphériques Bluetooth tous connectés à un hub Bluetooth afin d’augmenter non seulement le
nombre de connexions simultanées mais aussi pour augmenter sa capacité à supporter un flow
important de données. Nous avons ci-dessous deux exemples de hub Bluetooth :

Figure 13: Example of Bluetooth hub
Il peut jouer deux principaux rôles notamment celui de routeur et de relaie. Dans le cas où il joue
le rôle de relai, il est appelé BTS Bluetooth. Et dans le cas où il est joue le rôle de maître dans un
piconet, on l’appellera BSS Bluetooth pour Bluetooth Base Station Subsystem. Ceci dit, il aura
pour principales fonctions :
 La formation et de la gestion des piconets
 La réception et le relaie des différents signaux radio. C’est-à-dire la réception des demandes de
communication et l’acheminement de création du canal de communication entre l’expéditeur et
le destinataire. En d’autres termes, il sera chargé de créer un canal de communication entre deux
utilisateurs souhaitant communiquer.
 Le cryptage et le décryptage des données circulant sur le réseau
 Le routage des paquets entre les différents terminaux Bluetooth
 La gestion de l’activation et de la désactivation d’un lien vers une station mobile Bluetooth.
 Eventuellement la gestion de la mobilité des nœuds mobiles c’est-à-dire le handover.
 Il se chargera aussi de la manager le réseau, les abonnés (les utilisateurs), les services, et biens
d’autres.
Pour garantir une bonne visibilité des équipements et une plus grande portée des nœuds routeurs,
nous aurons besoin d’un pylône qui pourra être placé au-dessus d’un immeuble ou d’un bâtiment
de plus de deux étages. Voici en quelques sortes à quoi ressemble notre Nœud routeur dans la figure
ci-dessous. La petite case au pied du pylône représente une salle de contrôles où sont logés les
différents serveurs qui serviront de à interpréter et à traiter le flux d’information qui arrive au
niveau du nœud.
Figure 14: Exemple de nœud routeur appelé BTS Bluetooth
III.4. ARCHITECTURE DE LA PLATE-FORME
III.4.1. Architecture graphique étendue de notre solution

Figure 15: Architecture graphique étendue de notre solution
Cette architecture présente un scénario de communication entre deux utilisateurs A et B qui ne

sont pas dans le même nœud routeur. Comme nous pouvons le constater, l’utilisateur B est derrière
un bâtiment. Mais cela ne pose pas un problème majeur pour la technologie Bluetooth car
contrairement à l’infrarouge, elle passe à travers les murs. Cette architecture a été en partie inspirée
de l’architecture GSM classique qui a prouvé son efficacité partout dans le monde. Mais dans notre
cas, deux périphériques ont la possibilité de communiqué s’ils sont à portée l’un de l’autre. Et la
gestion des BTS et des BSC est différente dans ce sens qu’ici, chaque BSC gère uniquement une
seule BTS à laquelle est rattachée. Contrairement au GSM où une BSC peut gérer plusieurs BTS.
III.4.2. Protocole de formation des scatternet

Pour chaque collection d’équipements Bluetooth, il est nécessaire de définir un protocole de
formation des piconets, d’affectation des nœuds esclaves aux piconets et de liaison des différents
piconets entre eux afin d’obtenir un scatternet. Pour cela, nous allons d’abord faire le tour des
différents protocoles de formation de scatternet qui existent avant de présenter celui que nous avons
publié dans un article scientifique à une conférence [NON 12]. Nous avons appelé ce protocole
Bluetooth BTCP car il a été inspiré de BTCP que nous présentons ci-dessous.
III.4.2.1. Les protocoles de formation de scatternet existants dans les réseaux ad-hoc:
Plusieurs protocoles existent pour la formation des scatternets dans les réseaux Bluetooth. Nous
pouvons citer entre autre :
Le protocole BTCP (Bluetooth Topologie Control Protocol) proposé par Salonidis Theodoros en
2001 [SAL 01] BTCP est constitué de trois principales phases :
Phase1 : Election d’un coordinateur
C’est dans cette phase qu’un coordinateur est choisi en accord avec tous les autres périphériques.
Le procédé sera décrit dans notre protocole plus bas. La compétition de leadership continue tant
qu’il y a encore des candidats non conquit par le futur SUPER MASTER.
Phase2 : Définition des rôles
Le coordinateur détermine et informe les autres périphériques sur le rôle qu’ils auront à jouer
lors de la formation du scatternet.
Après la phase1, un coordinateur est élu. Il commence d’abord par déterminer le nombre total N
de nœud qu’il a conquis.
Si N<8 alors il forme rapidement un piconet en envoyant un message de connexion à tous les
périphériques « perdants » dont il a collecté les paquets FHS.
Si N>7 il y aura formation de plus d’un piconet. Le coordinateur ayant une vue globale du
réseau, va décider du rôle que chaque périphérique aura à jouer dans le future scatternet. Si la
formation du scatternet doit respecter un critère particulier il devra être tout simplement ajouté dans
les paquets FHS que les autres périphériques communiquent au coordinateur pendant la phase
d’élection. En considérant les paramètres par défaut, le coordinateur détermine le nombre de
piconets qu’il devra former. Pour cela, il utilise la formule suivante :
√
, 1≤N≤36 [SAL 01]
Où N est le nombre de nœud devant former le scatternet. Comme on le remarque dans la relation,
N≤36 pour limiter la saturation du réseau. Après la détermination de P (nombre de piconets), le
coordinateur choisi en plus de lui P-1 autres nœuds qui seront maîtres dans leur piconet et
autres nœuds pour qui serviront de pont entre les différents piconets [SAL 01]. Ensuite le

coordinateur distribue à chaque nouveau maître la liste des nœuds qui seront leurs esclaves sans
oublier les siens.
Après cette la définition des rôles, pour chaque maître, le coordinateur possède une liste
d’esclave SLAVELIST(X) et une liste des ponts BRIDGELIST(X). Chaque entrée de ces listes
contient le paquet FHS du nœud associé de façon à permettre au maître correspondant d’envoyer
des messages unicast de connexion à chacun de ses esclaves.
Ainsi, le coordinateur se connecte aux différents maîtres qu’il aura choisi formant ainsi un
piconet temporaire afin de leur transmettre à chacun leurs listes respectives de SLAVELIST et de
BRIDGELIST. Il leur ordonne ensuite d’établir la connexion avec leurs différents esclaves (phase3)
avant de détruire le piconet temporaire qu’il avait formé.
Phase3 : Etablissement des connexions

C’est dans cette phase que les liens sont établis entre les différents maîtres et leurs esclaves
respectifs qui sont chacun à l’état PAGE SCAN à l’attente d’une demande de connexion de la part
d’un maître. Les nœuds intermédiaires pour leurs parts sont aussi dans l’état PAGE SCAN mais à
l’attente de deux demandes de connexion de la part des deux maîtres. La connexion du scatternet est
complète lorsque chaque maître reçoit une notification de la part de tous set nœuds pont.
 On a ensuite le protocole de Ching Law [CHI 02] qui dans son article « A new Bluetooth
Scatternet Formation Protocol » paru en 2002 proposent un nouvelle algorithme de formation de
scatternet en optimisant le nombre de piconets et assurant l’appartenance pour un nœud donné à
 On a aussi le protocole d’Agrawal [AGG 00] qui introduit un algorithme de formation de

au plus deux piconets.
scatternet hiérarchique. son algorithme partitionne d’abord le réseau en piconet indépendants.

Ensuite, il élit un super master qui a une vue globale de tous le réseau.
III.4.2.2. NOTRE PROTOCOLE DE FORMATION DES SCATTERNETS

(BLUETOOTH BTCP)
On doit pouvoir obtenir un protocole de formation de scatternet qui réduit au maximum le
nombre de piconets car plus le nombre de piconets augmente, plus le nombre de collisions dans le
réseau augmente du fait du nombre de relais de connexion des différents piconets. Il faut rappeler
que d’après notre architecture, nous disposons de plusieurs nœuds fixes qui se chargeront de gérer
le réseau et le routage des paquets en circulation dans le réseau. Donc notre protocole de formation
de scatternet sera constitué de 3 phases comme dans le protocole BTCP proposé par Salonidis
Theodoros [SAL 01] et sur celui d’Aggarwal [AGG 00] dont nous avons décrit les principales
phases plus haut.
Lors de la mise en place de notre réseau, des configurations minimales doivent être opérées. Ces
configurations consistent en fait à définir le rôle de chaque nœud routeur dans le réseau. Dans notre
cas, les deux premières phases ne se feront que lors de l’initialisation du réseau et sur commande
lorsqu’une modification sera opérée dans le réseau (Ajout, modification de la position ou
suppression d’un périphérique ou d’un nœud routeur du réseau).
III.4.2.2.1. Phase1: Election d’un SUPER MASTER:

Elle est identique à l’élection du coordinateur dans le protocole BTCP à la seule différence que
dans notre cas, les nœuds en compétition ne sont rien d’autres que les nœuds routeurs. Pour assurer

cette contrainte, nous avons ajouté dans les messages FHS 1 [ICU 03] une constante permettant
d’identifier les nœuds routeurs de façon générale les nœuds routeurs et de limiter la participation
des autres nœuds mobiles à l’élection. Puisque ces nœuds sont fixes, cette phase ne se fera que lors
de l’initialisation du réseau ou lors de la modification du réseau comme nous l’avons précisé
précédemment.
Au début de l’élection, chaque nœud routeur possède un variable appelée VOTE qui est
initialisée à 1. Pendant le processus, lorsque deux nœuds se découvrent, ils comparent la valeur de
leur variable VOTE. Celui qui aura le plus grand nombre de vote i.e. dont la valeur de la variable
VOTE sera la plus grande, est considéré comme le gagnant (X) et l’autre comme le perdant (Y) de
la manche. Ainsi, le perdant transfère au gagnant la totalité des paquets de contrôle FHS qu’il aura
gagné ou conquis des autres nœuds routeurs avant de passer en mode PAGE SCAN (mode dans
lequel il ne devra plus recevoir d’INQUIRY MESSAGES) pour attendre un message de connexion
de la part du SUPER MASTER. Le gagnant incrémente alors son nombre de vote à la valeur de
celui du perdant (VOTE(X)= VOTE(X) + VOTE(Y)) et passe en mode INQUIRY2 et INQUIRY
SCAN3 i.e. il envoi des messages « inquiry » à tous les autre périphériques en même temps qu’il en
attend. La compétition de leadership continue ainsi tant qu’il y aura encore des candidats.
Une question demeure tout de même en suspens à savoir : comment le nœud X sait s’il est le
gagnant final? En fait, chaque nœud possède une variable temporelle Ω qu’il compare au temps
mis depuis la dernière élection ou confrontation qu’il a eu. Lorsque ce temps est dépassé, il se
considère directement comme le gagnant. Avant l’expiration de ce temps, il est comme nous l’avons
dit en écoute permanente du réseau (INQUERY, INQUERY SCAN). A la fin de la compétition, si on
avait N participants à l’élection, le super master X aura les paquets FHS de tous les N-1 autres
nœuds et sera le coordinateur du processus de formation du scatternet. Nous avons préféré ne pas
déterminer la fin de l’élection par le nombre de nœud en compétition pour éviter qu’un nœud en
disfonctionnement ne crée une rupture qui ferait boucler les autres nœuds indéfiniment.
III.4.2.2.2. Phase 2 : définition des rôles pour chaque nœud :

Dans notre cas, la définition des rôles sera très sélective comme dans la précédente phase. Les
nœuds qui joueront les rôles de masters et de ponts seront par défaut les nœuds routeurs. Dans cette
phase, le coordinateur sera chargé de définir le rôle de chaque nœud routeur dans le réseau. Un
nœud routeur peut être MASTER ou BRIDGE4 ou même jouer les deux rôles.
Pour cela, le SUPER MASTER commence d’abord par vérifier si le nombre de nœuds ayant
participé à la formation du scatternet est inférieur à 8, le cas échéant, il va directement leur envoyer
des demandes de connexion pour former avec eux un piconet dont il sera le maître.
Si le nombre de nœuds est supérieur ou égal à 8 alors il y aura formation de plusieurs piconets.
Ayant une vue globale du réseau, le SUPER MASTER va définir une liste de nœuds routeurs qui
vont jouer le rôle de master. Et pour chacun des nœuds master de la liste, il va définir une autre liste
de nœuds pont (BRIDGE) associée qui auront pour rôle d’interconnecter le piconet aux autres dans
le scatternet en formation.
1
FHS : Frequency Hopping Synchronization
2
INQUIRY : Lorsqu’un périphérique désire découvrir les nouveaux dispositifs dont il ne connait pas l’adresse.
3
INQUIRY SCAN : Lorsqu’un périphérique désire recevoir des paquets « inquiry », il entre en mode « inquiry
scan
4
BRIDGE=pont

 Le nombre de piconet à former (en occurrence le nombre de maître) est déterminé par la
relation suivante:
�
�= , 1 ≤ K ≤ 7, 1 ≤ N ≤ 36. Relation 1: Nombre de piconets
�
Où N est le nombre de Nœuds routeurs en compétition, K le nombre de nœuds esclaves par

piconet et . Cette relation est obtenue par
récurrence sur le nombre de nœud en compétition.
 Le nombre de nœuds de relai (pont) pour sa part est déterminé par la relation suivante :
� �
�= , où P est le nombre de piconets. Relation 2: nombre de nœuds de relai
A noter que deux piconets ne peuvent partager plus d’un pont. Cette contrainte nous permet de limiter le
nombre de ponts et par occurrence la saturation du réseau.
Pour la preuve des deux relations précédentes, voir annexe1.
Après tous ces calculs, le SUPER MASTER procède alors à l’attribution des rôles à chaque
nœud routeur en envoyant à chacun des masters sa liste des nœuds pont (BRIDGELIST) et à chaque
nœud pont les ID de ses différents nœuds maîtres (nous limitons cette liste à deux pour le moment
en attendant étudier plus en profondeur les différents paramètres qui nous permettront d’augmenter
ce nombre). Pour l’établissement de la connexion, entre les différents masters, le SUPER MASTER
donne l’ordre aux maîtres d’envoyer les demandes de connexion à leurs différents nœuds ponts pour
ainsi initier la formation des piconets. Lorsqu’un nœud pont reçoit une demande de connexion de la
part d’un maître, il vérifie si cette demande provient de l’un de ses deux maîtres. Si tel est le cas, il
accepte la demande et renvoie une notification à ce dernier s’il est le deuxième master à lui envoyer
la demande. Sinon il rejette tout simplement la demande. Lorsqu’un maître reçoit des messages de
notification de tous ses nœuds ponts, on peut considérer que la formation du scatternet se passe dans
les meilleures conditions. La connexion étant établies entre les différents maîtres, vient alors la
phase de formation des piconets complets avec les nœuds mobiles.
III.4.2.2.3. Phase 3 : Formation des piconets complets:

Après l’attribution des rôles à chaque nœud routeur (en fonction du nombre de nœud entrants en
jeux dans la formation du scatternet), le SUPER MASTER donne donc l’ordre à chacun d’eux de
former son piconet. Pour cela, chaque nœud routeur envoie des demandes de connexion à tous les
périphériques situés dans son rayon de portée pour former un piconet dont il sera le maître. Ce
piconet sera ainsi constitué uniquement de périphériques qui auront acceptés sa demande. Pour un
nœud situé dans le champ ou dans le rayon de portée de plusieurs nœuds routeurs, l’application
cliente sera chargée de choisir qui sera son maître. Ce choix dépendra de la force du signal
(exprimée en décibel) émise par le demandeur (le nœud routeur). Ainsi, celui dont le signal de
transmission sera le plus fort sera choisi comme master par le nœud mobile. Nous avons choisi ce
paramètre pour prendre en compte la gestion de la mobilité1 dans notre réseau car nous avons
affaire à un réseau mobile où les nœuds sont constamment en mouvement. Si un nœud mobile ne
1
Handover

reçoit qu’une seule demande après un temps ‘α’ qu’on fixera en fonction de la densité du trafic, il
n’aura pas besoin de vérifier la force du signal.
III.4.3. Protocole de routage

Le protocole utilisé doit respecter un certain nombre de contraintes. On peut citer entre autres :
- La garantie d’une bonne qualité de service i.e. une bonne fluidité de la qualité de la
communication.
- L’utilisation optimale des ressources pour limiter les saturations du réseau et les consommations
abusives d’énergie électrique.
- La prise en compte de la position des nœuds communicants i.e. pouvoir identifier efficacement à
quel nœud routeur un périphérique est connecté dans le réseau.
- la prise en compte de la formation et de la reconfiguration des scatternets.
On distingue plusieurs types de protocole de routage dans les réseaux ad-hoc: les protocoles de
routage proactifs, les protocoles de routage réactifs et les protocoles de routage hybrides [TRA 09].
III.4.3.1. Les protocoles de routage proactifs

En ce qui concerne les protocoles proactifs, chaque nœud a une table de routage qui est mise à
jour régulièrement grâce à l’utilisation des messages de contrôle que les différents nœuds
s’échangent entre eux. Ici, les procédures de création et de maintenance des routes sont contrôlées
périodiquement. Cette maintenance reste toujours active même s’il n’y a pas de trafic dans le
réseau. Les deux principales méthodes utilisé dans le cas des protocoles de routage proactifs sont :
la Link state et la méthode Distance Vector.
III.4.3.1.1. Link State : [ANE 02]

Dans cette méthode, chaque nœud garde une vision de toute la topologie du réseau et ce par
l’intermédiaire des requêtes périodiques portant sur l’état des liaisons avec les nœuds voisins.
III.4.3.1.2. Distance Vector: [MAH 06]

Dans cette méthode par contre, chaque nœud diffuse à ses nœuds voisins sa vision des distances
qui le séparent de tous les hôtes du réseau. En se basant sur les informations reçues des autres
voisins, chaque nœud de routage fait un certain calcul pour trouver le chemin le plus court vers
n'importe quelle destination. Cette technique est basée sur l’algorithme distribué de Bellman et Ford
1
qui permet de trouver des plus courts chemins, depuis un sommet source donné, dans un graphe
orienté pondéré.
Parmi les protocoles proactifs les plus connus nous pouvons citer : DSDV (Destination-
Sequenced Distance Vector). [GUO 03], B.A.T.M.A.M, OLSR, FSR que nous allons décrire dans la
suite.
III.4.3.1.3. Quelques exemples de protocoles de routage proactifs
III.4.3.1.3.1. Le protocole DSDV (Destination-Sequenced Distance

Vector). [GUO 03]):
C’est un protocole à vecteur de distance inspiré de l’algorithme de Bellman Ford (DBF :
Distributed Bellman-Ford). C’est une sorte d’adaptation du protocole de routage RIP (Routing
Information Protocol) aux réseaux ad-hoc. Chaque nœud du réseau possède une table de routage
1
Algorithme distribué de Bellman et Ford : http://fr.wikipedia.org/wiki/Algorithme_de_Bellman-Ford

contenant toutes les destinations possibles dans le réseau, le nombre de saut nécessaire pour
atteindre chacune de ces destinations et le numéro de séquence de correspondant à chaque potentiel
nœud destination. Le numéro de séquence permet d’éviter les boucles de routages et de distinguer
les anciennes routes des nouvelles après chaque mise à jour. Lorsqu’un nœud reçoit de nouvelles
données de routages il les compare aux siennes. pour déterminer la meilleure route à utiliser pour
communiquer, il utilise tout simplement le numéro de série et choisi la route ayant le plus grand
numéro de série. Voici par exemple une topologie réseau et la table de routage correspondant au
nœud M1 :
Figure 16 : exemple d'un réseau ad-hoc
Table 2 : table de routage correspondant au nœud M1 dans le graphe ci-dessus
Destination Nombre de sauts Prochain nœud Numéro de séquence

M1 0 M1 NS1
M2 1 M2 NS2
M3 2 M2 NS3
M4 1 M4 NS4
M5 2 M4 NS5
M6 3 M4 NS6
III.4.3.1.3.2. Le protocole B.A.T.M.A.N1 (Better Approach To Mobile Ad-

hoc Networking)
B.A.T.M.A.N. [AXE 07] est un protocole de routage proactif actuellement développé par la
communauté Freifunk2. Il tend à remplacer le protocole OLSR 3 dont il tire une grande partie de son
inspiration. Comme tout protocole, il permet à chaque nœud du réseau de découvrir les autres
nœuds du réseau et de calculer la meilleure route vers ces derniers. Le nœud informe ensuite ses
voisins de sur les nouveaux nœuds et sur les routes vers ceux-ci. Depuis sa version 34,
B.A.T.M.A.N. permet de gérer à la foi les réseaux sans fils et les réseaux câblés classiques tels que
Ethernet5. L’automatisation de la découverte des routes pour le cas des réseaux sans fils permet à
chaque nœud de découvrir la meilleure route en fonction de la puissance des signaux émis sur le
réseau.
1
http://fr.wikipedia.org/wiki/B.A.T.M.A.N.
2
http://wiki.freifunk.net/ Freifunk communauté qui travaille dans le développement des applications liées aux
réseaux maillées.
3
http://en.wikipedia.org/wiki/Optimized_Link_State_Routing_Protocol
4
http://fr.wikipedia.org/wiki/B.A.T.M.A.N.#B.A.T.M.A.N._Version_3
5
Ethernet est un protocole de réseau local à commutation de paquets http://fr.wikipedia.org/wiki/Ethernet

Le principe de fonctionnement de B.A.T.M.A.N. est assez simple : chaque nœud envoie de façon
régulière sur le réseau des messages de broadcast appelés ici OGM 1 (Originator Message) [AXE
07] pour informer ses voisins de son existence. Chaque voisin qui reçoit le message le revoit à son
tour à tous ses voisins pour les informer de l’existence de l’initiateur d’origine du message. C’est
ainsi que de proche en proche, chaque nœud du réseau est au courant de l’existence de ce nœud.
Pour trouver le meilleur chemin vers tous les voisins, chaque nœud B.A.T.M.A.N. mémorise pour
chaque origine le voisin qui lui a transmis le plus grand nombre de message provenant de cette
même origine. Pour limite les saturations du réseau, B.A.T.M.A.N. renvoie le message de réponse
uniquement par le nœud qu’il aura mémorisé comme étant le nœud ayant le plus grand nombre de
message provenant du nœud source, considérant qu’il possède le meilleur chemin vers le nœud
source.
III.4.3.2. Protocoles de routage réactifs

Dans ce cas, c’est à la demande d’une transmission des paquets de données par une source que
le contrôle des routes les tables de routage sont mises à jour. Dans ce cadre plusieurs politiques
peuvent être adoptées, les plus importantes sont les suivants :
III.4.3.2.1. La Technique d’apprentissage en arrière :

Encore appelé backward learning [ANN 06]: cette technique d’apprentissage est basée sur le fait
que, lorsqu’un nœud source veut transmettre un message à un nœud destination, il procède tout
d’abord à la diffusion par inondation d’une requête sur l’ensemble du réseau. Ainsi, chaque nœud
intermédiaire qui reçoit le message informe à son tour le nœud source de la réception du message.
Lorsque la requête arrive au nœud destinataire, ce dernier transmet sa réponse sous forme de
requête au nœud source en suivant le même chemin par lequel la requête est arrivée.
III.4.3.2.2. Technique du routage source :

Dans cette technique, le nœud source détermine toute la liste des nœuds par lesquels doit
transiter le message, ainsi le nœud émetteur inclut dans l’entête du paquet une route source. En
effet, afin de construire la route, le nœud source doit préciser les adresses exactes des nœuds par
lesquels le message transitera jusqu'à atteindre le destinataire. Ainsi, le nœud source transmet le
paquet au premier nœud spécifié dans la route. Notons que chaque nœud par lequel le paquet transit,
supprime son adresse de l’entête du paquet avant de le retransmettre. Une fois que le paquet arrive à
sa destination, il sera délivré à la couche réseau du dernier hôte.
Parmi les protocoles de routage réactifs les plus utilisés, on peut citer : AODV, TORA, DSR.
III.4.3.3. Protocoles de routage hybrides

Le protocole hybride combine les deux logique de routage précédentes notamment celle des
protocoles proactifs et actifs. Il utilise les techniques des protocoles proactifs pour avoir les
informations sur ses voisins les plus proches i.e. à moins de 2 sauts. Au-delà de deux sauts, le
protocole hybride fait appel aux techniques des protocoles réactifs pour avoir les routes. On peut
citer entre autres protocoles hybrides les protocoles ZRP (Zone Routing Protocol) et CBRP, sont
deux exemples de protocoles hybrides. Le protocole de routage ZRP [NIC 01] utilise les deux
approches (Proactif et Réactif). Il limite la procédure proactive uniquement aux nœuds voisins et la
procédure réactive pour les nœuds à plus d’une distance définie en termes de nombre de sauts. Une
1
Ce sont des paquets de 52bits contenant l’adresse le l’émetteur (nœud d’origine), l’adresse du nœud de relai du
message, le numéro de séquence et la TTL (Time To Live) qui est la durée de vie du paquet.

zone de routage est alors définie pour chaque nœud du réseau. ZRP utilise en fait deux protocoles
de communication : IARP (IntrAzone Routing Protocol) [ZYG 03] pour les communications locales
à une zone et IERP (IntErzone Routing Protocol) [ZYG 02] pour les communications entre les
différentes zones.
III.4.3.4. NOTRE PROTOCOLE DE ROUTAGE : BRProtocol (Bluetooth Routing

Protocol)
Considérons notre modèle réseau définit précédemment, i.e. un ensemble de nœuds fixes (nos
nœuds routeurs) et les nœuds mobiles qui sont chacun liés à un nœud fixe. Nous avons
précédemment défini notre protocole de construction du scatternet associé à notre topologie réseau.
Ce protocole nous a permis d’obtenir un scatternet qu’on peut considérer comme étant à moitié
hiérarchique d’une part et à moitié plate d’autre part donc avec une structure hybride.
L’aspect hiérarchique est perceptible par la présence des nœuds routeurs qui sont fixes et qui
sont chargés de relayer les signaux vers un destinataire hors porté de son émetteur. Et on a aussi le
SUPER MASTER élu lors dans la première phase de notre protocole de formation de scatternet qui
a une vue globale sur l’ensemble du réseau. Les autres nœuds routeurs remontent jusqu’à lui toutes
les informations concernant les nœuds mobiles qui leurs sont attachés notamment la BD_ADDR1
(Bluetooth Device Address).
L’aspect plate vient du fait que tous les nœuds routeurs peuvent s’échanger des données sans
pour autant passer par le SUPER MASTER. Et aussi, les différents nœuds mobiles peuvent
communiquer en point à point sans être obligé de passer par le nœud routeur auquel ils sont
attachés.
Chaque nœud routeur entretient une table de routage qui lui permet de savoir tous ses nœuds
voisins et surtout l’ensemble de ses esclaves (l’ensemble de ses nœuds mobiles).. Nous allons dans
la suite définir la structure des différentes tables de routage et la procédure de routage qui sera
utilisée dans notre réseau.
III.4.3.4.1. Table de routage

Après la formation du scatternet, le superviseur (le nœud routeur qui suppervise la formation du
scatternet) construit sa table de routage. Cette table est en fait identique à celle de tous les autres
nœuds routeur à la seule différence qu’elle est mise à jours plus fréquement que celle de tous les
autres nœuds. Elle contient l’ensembles des informations échangées entre les différents participants
pandant le processus de formation du scatternet ainsi que les informations concernant les différents
piconets.
Lorsqu’un nœud mobile choisi un nœud routeur comme son maître pour une première foi, ce
dernier (le nœud routeur) l’enregistre dans un premier temps comme étant un visiteur dans le
piconet. En fonction de la fréquence de ce nœud dans le piconet il pourra être enregistré comme
nœud locataire du piconet. Les mises à jours des tables de routatge de chaque nœud routeur ne se fera que
lorsqu’un changement sera opéré un piconet quelconque. Commen changement, nous avons par exemple la
perte de connexion entre un nœud mobile et un nœud routeur.
1
C’est l’adresse matérielle des périphériques Bluetooth équivalent à l’adresse Mac d’une carte réseau. Ces adresses
sont codées sur 48bits et sont gérées par l’IEEE Registration Authority.

III.4.3.4.2. Procedures de routage

Notre protocol sera constitué de deux principales phases : la recherche des routes et l’échange
des informations (la voix dans notre cas) via la route trouvée. Pour ce qui est de la recherche des
routes, notre protocole est réactif dans ce cas. Ceci pour éviter la saturation du réseau par des
messages de routage échangés par les différents nœuds de façon permanante dans le réseau. C’est
pourquoi nous avons choisi de découvrir les routes lors de l’initiation d’une communication par un
nœud mobile en destination d’un autre. De même au niveau des piconets i.e. entre chaque maître et
l’ensemble de ses esclaves (les nœuds mobiles) nous avons prévue un fonctionnement réactif pour
limiter la consomation de l’énergie au niveau des périphériques mobiles. Lorsqu’un nœud mobile
veut communiquer avec un autre nœud du réseau, il lance d’abord lancer une recherche autour de
lui pour savoir si ce nœud est dans son entourage i.e. dans son rayon de portée. Si c’est le cas, il y a
établitablissement d’une liason synchrone entre les deux nœuds leur permettant ainsi de pouvoir
comuniquer. Si tel n’est pas le cas, ce nœud (mobile) initie donc une demande de communication au
point d’acces (nœud routeur) qu’il aura choisi comme maître. Cette demande comporte entre
autres : les informations du nœud dans le piconet notamment sa BD_ADDR, les infomations sur
son horloge, et les informations sur le nœud destinataire. Ce sera donc au nœud routeur de trouver
le nœud en question et de définir la route idéale pour que les deux nœud puisse communiquer.
III.4.3.4.3. Gestion de la mobilité des équipements

Afin de savoir à tout moment à quel nœud routeur appartient un nœud mobile, nous procédons de
la manière suivante : lorsqu’un nœud mobile se connecte à un point d’accès, ce dernier met à jour sa
table de routage pour signaler qu’un nouveau nœud s’est connecté au réseau. De même, lorsqu’un
nœud mobile perd la connexion avec son nœud routeur, le point d’accès met à jour sa table de
routage pour signaler que ce nœud (mobile) n’est plus présent dans le piconet. Lorsque l’une des
deux situations précédentes survient, le nœud routeur concerné informe alors les autres du
changement pour qu’ils puissent mettre à jour leur table de routage.
III.5. ETUDE DES ENJEUX ECONOMIQUES DE LA SOLUTION.
Ici, nous allons faire une étude de la faisabilité technique et économiques de notre solution avec
une petite études des coûts de déploiement de celle-ci.
Nous allons commencer par la mise au point d’un nœud routeur. Comme nous l’avons dit plus
haut, notre nœud routeur sera un assemblage de plusieurs clés Bluetooth relié en USB à un hub
Bluetooth. le prix d’un hub Bluetooth dépend du nombre de port usb qu’il dispose. Un hub de 5
ports coutera sensiblement 100 € [TWE 12]. Les clés Bluetooth qui sont en fait des périphériques
Bluetooth de classe11 couteront pour leur part environ 20€ donc pour 5 clés par hub Bluetooth on
aura un total de 100 €.
Pour garantir une bonne portée du signal, on aura besoin d’un pylône de plus de 20 mètres qui
va couter pratiquement 1000 €. Pour réduire les couts du pylône, on peut exploiter un bâtiment de à
plusieurs niveau sur lequel on aura juste besoin d’un support de moins de 5 mètres pour installer
notre nœud routeur.
Pour gérer les demandes de communication est le routage des signaux, on aura besoin d’un
serveur qu’on peut estimer à 1000 € en fonction des caractéristiques de ce dernier. Ce serveur sera
installé dans une sale démilitarisée de préférence dans le même bâtiment que celui sur lequel est
1
Classe 1 : avec une puissance de 100 mW (20 dBm) et une portée de 100 mètres

placé le nœud routeur. Ce serveur est en fait le moteur du nœud routeur avec qui il va échanger
permanemment des informations. Dans le cas d’un réseau GSM ce serveur est appelé BSC qui peut
gérer plusieurs BTS qui sont les nœuds routeur. Dans notre cas, chaque BSC est associé à une seule
BTS.
En prenant en compte d’autres accessoires à 300 €, notre estimation nous donne un total de 2500
€ pour notre BSC Bluetooth contre un montant de pratiquement 160 000 € pour une solution GSM
d’après l’estimation de Julien Delmas dans son livre « Les Relais GSM » [DEL 06].
Table 3: RECAPUTULATIF estimation d’un nœud routeur
Materiel Nombre Prix unitaire € cout total €

clés Bluetooth 5 20 100
hub Bluetooth 1 100 100
pylône 1 1000 1000
serveur 1 1000 1000
Autres accessoires * 300 300
TOTAL 2500 €
Si on veut par exemple déployer notre solution dans un campus universitaire, comme celui de
l’Ecole National Supérieur Polytechnique de Yaoundé, on aurra sensiblement besoin de deux nœuds
routeurs ce qui nous fera un total de 8000 € pour les nœuds routeurs et autres soit environ 5.240.000
FCFA.
Table 4: estimation du déploiement de l'application dans un campus universitaire
Materiel Nombre Prix unitaire € cout total

Nœud routeur 2 2500 5000 €
Application et Protocoles * 1500 1500 €
Main d’oeuvre * 300 300 €
Communications et deplacements * 100 100 €
Autres * 100 100 €
TOTAL 8000 €
≈ 5.240.000 FCFA

CHAPITRE IV. MISE EN ŒUVRE DE LA SOLUTION

Nous allons dans cette phase présenter la plateforme logicielle que nous aurons développée pour
permettre la communication (par échange de la voix) entre deux périphériques Bluetooth. Cette
application sera faite sous la plateforme Android et permettra de faire passer la voix par Bluetooth
d’un périphérique à un autre (en mode point à point) comme le montre la figure ci-dessous :
Figure 17: communication point à point entre deux utilisateurs A et B
Nous avons choisi Android car en plus de son expansion de plus en plus croissante dans le
domaine de la téléphonie, elle offre aussi plusieurs facilités quand il s’agit de travailler directement
avec la couche physique du téléphone comme le micro, les hauts parleurs, le Bluetooth et autres qui
sont nécessaires pour l’enregistrement, le transfère et aussi la réception de la voix.
IV.1. Analyse des besoins
IV.1.1. Besoins fonctionnels

Notre application doit être capable de faire passer la voix d’un périphérique Bluetooth à un autre
afin de leur permettre de communiquer. Pour cela, nous avons défini les différentes actions
suivantes. Un utilisateur doit pouvoir : Créer un profile utilisateur, Rechercher un équipement, Se
connecter à un équipement, Initier une conversation avec un autre, Terminer la conversation,
Paramétrer l’application, Modifier le profil utilisateur, Changer la langue, Activer ou désactiver son
Bluetooth, Ajouter un contact Bluetooth, Supprimer un contact Bluetooth, Consulter le répertoire
des contacts Bluetooth, Se déconnecté, Quitter l’application.
Diagrammes des cas d’utilisations
Figure 18: diagramme des cas d'utilisations

IV.1.2. Besoins non fonctionnels

 Version d'Android. Pour pouvoir utiliser l'application il est nécessaire de posséder une version
d’Android supérieure ou égale à la 2.1 pour la prise en compte du Bluetooth.
 En ce qui concerne le temps réel, le temps entre le moment où l’émetteur parle et le moment où
le récepteur (connecté) l’entend doit être le plus court possible.
 En termes d’énergie, l'application doit avoir un coût d'utilisation de la batterie le plus faible
possible.
IV.1.3. Ressources (matérielles, logiciel, humaines)

- Matérielles : Un ordinateur pouvant supporter l’environnement de développement Eclipse et
l’émulateur Android. Deux smart phones Android minimum avec Bluetooth pour les tests.
- Logiciel : Eclipse : qui est la plateforme de développement utilisée, dont la dernière version
eclipse-jee-juno est disponible en téléchargement à l’adresse suivante :
http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/juno/
R/eclipse-jee-juno-win32.zip.
La machine virtuelle java JDK
Android SDK : la dernière version du SDK Android (android-sdk_r20.0.3-windows) et les
différents plugins associés. Notamment, l’ADT (Android Developper Toolkit) pour Eclipse
- Humaine: comme ressource humaine on peut compter un développeur java.
IV.2. Présentation de la plateforme Android
Voir ANNEXE C :
IV.3. Conception de l’application
IV.3.1. Acteur du système.

Nous avons un seul acteur qui intervient sur le système et qui n’est rien d’autre que l’utilisateur
de l’application.

IV.3.2. Diagramme d'états
Figure 19: diagramme d'état de notre application
Notre application dispose plusieurs états. Lorsqu'on lance l'application, on est dans l'état initial.
 Etat initial : Dans cet état, le périphérique ne peut rien faire mis à part tenter de se connecter ou de
recevoir une demande de connexion de la part d’un autre périphérique
 Etat connecté : Une fois que le périphérique est connecté à un interlocuteur, il bloque toute autre
demande de connexion. Il ne peut cependant plus recevoir de nouvelles demandes de connexion.
Par défaut notre application est en mode half-duplex, donc lorsqu'on reçoit un message audio ou
lorsqu'on le transmet on passe dans l'état half-duplex qui permet d'éviter que l'on puisse envoyer et
recevoir du son en même temps.
 Etat half-duplex : Dans cet état un périphérique Bluetooth peut recevoir des messages de
connexion ou de déconnexion. Si jamais il venait à perdre la connexion avec son interlocuteur, il
retourne dans l'état initial. Le périphérique passe dans cet état quand l’utilisateur veut envoyer
l’application à son interlocuteur par transfert de fichier. Lorsque le transfert est terminé, l'envoi
terminé, il retourne dans l'état connecté. Et si dans cet état, l’application est détectée chez
l’interlocuteur, il passe alors à l’état full-duplex.
 Etat full-duplex : Dans cet état, le périphérique est prêt à communiquer avec son interlocuteur par
échange de messages vocaux. En principe, dans cet état, toutes les actions sont autorisées comme
par exemple recevoir des demandes connexion ou des messages de déconnexions des autres
interlocuteurs en même temps qu’on est en train de communiquer. Mais nous avons préféré bloqué
cette option par souci d’efficacité lors de la conversation entre les deux interlocuteurs après qu’ils
soient connectés. En revanche comme dans l’état précédent (half-duplex), si un périphérique perd la
connexion avec son interlocuteur il repasse directement dans l'état initial où il pourra établir la
connexion avec d’autres périphériques.

IV.3.3. Diagramme de séquence utilisateur/application

Sur ce diagramme, nous présentons les interactions entre deux utilisateurs par le biais de leur
téléphone. On a deux principales étapes distinctes. La première concerne la connexion entre les
deux périphériques et la seconde étape concerne communication entre les deux périphériques
(émission et de réception du son).
Figure 20: diagramme de séquence utilisateur/application

IV.3.4. Architecture logicielle
Figure 21: Architecture logiciel
Nous allons ici faire une brève description des différents éléments de notre architecture
logicielle.
 MainActivity : Cette classe représente la vue principale de notre application. Elle contient
un moteur qui permet aux classes dont elle dépend de pouvoir accéder et modifier
indirectement les éléments de l'interface graphique.
 BluetoothService : Classe réalisant les opérations liées à l’utilisation du Bluetooth.
 FindDevice : C’est la classe qui permet de faire la recherche de l’équipement avec lequel on
souhaite communiquer.
 VoiceRecoder : Elle permet d’enregistrer la voix
 VoiceReceiver : Cette classe permet d’écouter et de recevoir les données vocales entrantes.
 UserManager : Pour la gestion des utilisateurs
 PrefereceManager : Pour la gestion des préférences de l’application.
 Utilisateur : Représente les profils des différents utilisateurs du système : pseudo, login,
mots de passe et autres.
IV.4. Implémentation de l’application
Nous allons dans cette partie définir les différents points suivants :

IV.4.1. Définition des droits

Pour que notre application puisse utiliser le Bluetooth, le micro et le haut-parleur du téléphone,
nous devons lui donner ces différentes permissions:
 les permissions BLUETOOTH pour effectuer une quelconque communication Bluetooth,
par exemple une demande de connexion, l’acceptation d'une connexion, et le transfert des
données.
 les permissions BLUETOOTH_ADMIN qui servent à initier la découverte de périphériques
ou la manipulation des paramètres Bluetooth comme l’activation ou la désactivation du
Bluetooth, l’activation ou la désactivation de la visibilité du Bluetooth à partir de
l’application et toute autre configuration liée au fonctionnement de la puce Bluetooth.
 La permission RECORD_AUDIO: elle permet à l’application d’utiliser le micro du
téléphone
 La permission MODIFY_AUDIO_SETTINGS qui permet de modifier les paramètres
audio : volume et qualité du son.
 Les permissions ACCESS_NETWORK_STATE et ACCESS_NETWORK_STATE : elles
permettent de gérer l’aspect réseau. Avec ces deux permissions, l’application pourra vérifier
la force du signal réseau qu’elle reçoit et même la changer à volonté en fonction de ses
besoins.
Toutes ces différentes permissions sont définies dans le fichier manifest de notre application :
AndroidManifest.xml. Voici le contenu de ce fichier avec les différentes permissions et contraintes
(versions minimale du SDK nécessaire pour faire fonctionner l’application) que notre application
demande :
< manifest xmlns:android= "http://schemas.android.com/apk/res/android"

package= "com.androidapplication"
android:versionCode= "1"
android:versionName= "1.0" >
< uses-sdk
android:minSdkVersion= "9"
android:targetSdkVersion= "15" />
< uses-permission android:name= "android.permission.RECORD_AUDIO"/>
< uses-permission android:name= "android.permission.BLUETOOTH_ADMIN"/>
< uses-permission android:name= "android.permission.BLUETOOTH"/>
< uses-permission android:name= "android.permission.MODIFY_AUDIO_SETTINGS"/>
< uses-permission android:name= "android.permission.ACCESS_NETWORK_STATE"/>
< uses-permission android:name= "android.permission.CHANGE_NETWORK_STATE"/>
< application
android:icon= "@drawable/ic_launcher"
android:label= "@string/app_name"
android:theme= "@style/AppTheme" >
< activity
android:name= ".MainActivity"
android:label= "@string/title_activity_main" >
< intent-filter>
< action android:name= "android.intent.action.MAIN" />
< category android:name= "android.intent.category.LAUNCHER" />
< /intent-filter>
< /activity>
< /application>
< /manifest>
Algorithme 2: fichier AndroidManifest.mf

IV.4.2. Recherche des équipements

Pour permettre la communication entre deux équipements par Bluetooth, il faut d’abord que l’un
initie la recherche de l’autre avant de lui envoyer une demande de connexion. Pour cela, nous
utilisons la méthode RechercheEquipement de notre classe FindDevice Défini comme suit:
…
public void RechercheEquipement(BluetoothAdapter bluetoothAdapter) {
// on teste si la découverte n'est pas encore lancée avant de la lancer
// Resources myResources = getResources();
if(bluetoothAdapter.isDiscovering()){
bluetoothAdapter.startDiscovery();// lance la décourverte des équipements
}
if(!remote_device.equals(null)){
// S'il y a des équipements apareillés
if (pairedDevices.size() > 0) {
// Loop through paired devices
for (BluetoothDevice device : pairedDevices) {
//ajout du nom et de l'adresse des équipements décourvert
// Add the name and address to an array adapter to show in a ListView
if(device.equals(remote_device)){
bluetoothAdapter.cancelDiscovery();
break;
}
mArrayAdapter.add(device.getName() + "\n" + device.getAddress());
}
}
}
Algorithme 3: recherche des équipements
Dans cette méthode, le bluetoothAdapter est en fait le périphérique à découvrir. Dans ce cas il ne
contient qu’un seul périphérique car il est question de rechercher un périphérique dont on connait
l’adresse Bluetooth.
IV.4.3. Pairage et connexion de deux équipements

Le processus de connexion est défini dans notre méthode connectDevice(BluetoothContact
contact). Pour écouter les connexions entrantes, nous utilisons la méthode
listenUsingRfcomWithServiceRecord du BluetoothAdapter prenant comme paramètre un nom et un
UUID (identifiant universel que nous utilisons aussi pour simuler la notion de canal). Cette méthode
nous renvoie un BluetoothServerSocket.
Pour ouvrir une connexion, nous utilisons la liste des adresses physiques des périphériques
appariés. On récupère donc une liste de BluetoothDevice qui va nous permettre de faire appel à la
méthode createRfcommSocketToServiceRecord avec pour paramètre l'UUID (universally unique
identifier)1 adéquat (i.e. celui du périphérique avec lequel nous voulons nous connecté). Cette
1
Elle permet d’identifier l’application de façon unique

méthode renvoie un BluetoothSocket que nous avons appelé clientSocket qui nous permet donc
d'initier la connexion à l'aide de la méthode connect().
private UUID uuid = UUID.fromString("a60f35f0-b93a-11de-8a39-08002009c666");

…
public void connectDevice(BluetoothContact contact) {
Try{
interlocuter =getContact(contact.getAddress());
BluetoothDevice device = bluetooth.getRemoteDevice (interlocuter);
BluetoothSocket clientSocket = device.createRfcommSocketToServiceRecord(uuid);
clientSocket.connect();
} catch (IOException e) {
Log.d("BLUETOOTH", e.getMessage());
}
}
Algorithme 4: connexion des équipements
IV.4.4. Gestion de la communication vocale
IV.4.4.1. Enregistrement de la voix

Pour cela l’api Android nous propose les deux principales classes suivantes:
 AudioTrack
 AudioRecord
Ces deux classes permettent d’enregistrer les données audio directement du périphérique
d’enregistrement vocal du téléphone. Mais pour pouvoir utiliser l’enregistreur audio du téléphone, il
faut attribuer les droits adéquats à notre application :
< uses-permission android:name= "android.permission.RECORD_AUDIO"/>
Puisque notre application est une application temps réelle nous aurons besoin de préciser un
certain nombre de paramètres pour créer notre AudioRecord. Nous pouvons citer entre autres :
 La fréquence de communication,
 l’encodage audio,
 le nombre de canaux (mono ou stéréo),
 la taille du buffer qui sera par défaut la taille minimale du buffer de l’AudioRecord (qu’on
récupère grâce à la méthode getMinBufferSize). Cette taille dépend en général des autres
paramètres cités ci-dessus.
int bufferSize = AudioRecord.getMinBufferSize(frequency,channelConfiguration,audioEncoding);

AudioRecord audioRecord = new AudioRecord(MediaRecorder.AudioSource.MIC, frequency,
channelConfiguration, audioEncoding, bufferSize);
Pour lancer l’enregistrement du son qui va être envoyé en temps réelle à notre destinataire, nous
allons utiliser la méthode startRecording de l’audioRecord que nous avons défini précédemment.

audioRecord.startRecording(); //lancement de l’enregistrement

//enregistrement des données dans le buffer
short[] buffer = new short[bufferSize]; // buffer pour l’enregistrement du son
while (isRecording) {
[ ...]
int bufferReadResult = audioRecord.read(buffer, 0, bufferSize);
}
Algorithme 5: enregistrement du son
IV.4.4.2. Envoi du son par Bluetooth

C’est la methode sendTo de notre thread qui gère l’envoi du son par Bluetooth.
public void sendTo(String address, byte[] data) {

if(D) Log.v(TAG, TAG+ " sendTo("+ address+ ", data)");
synchronized(connectedThreads) {
connectedThreads.get(address).write(data);
}
}
Algorithme 6: envoi du son par Bluetooth
En fait dans notre run lorsqu’on détecte une entrée audio, on l’enregistre comme une nouvelle
donné à envoyer. Lorsque La taille maximale de notre buffer est atteinte, on lance le transfert au
périphérique de l’interlocuteur.
[…]
interlocuter =getContact(contact.getAddress());
byte [] data = new byte[dataLength];
data[0] = MSG_DISCONNECTION;
sendTo(interlocuter ,data);
[…]
Algorithme 7: envoi du son par Bluetooth (2)
IV.4.4.3. Réception et lecture du son

C’est la méthode play(…) de l’AudioAdapter qui nous permet de lire le son venant de
l’interlocuteur :

public void play(String id, byte[] buffer) {

try {
audioTracks.get(id).write(buffer, 0, bufferSize);
} catch(NullPointerException e) { // First "play" for this id
AudioTrack audioTrack = new AudioTrack( AudioManager.STREAM_MUSIC, rate, channel,
format, audioTrackBuf, AudioTrack.MODE_STREAM);
audioTrack.setStereoVolume(1.0f, 1.0f);
audioTrack.play();
audioTracks.put(id, audioTrack);
}
}
Algorithme 8: lecture du son chez l'interlocuteur
Le processus de lecture est un peu plus complexe que ça. En fait on passe par la détection de
l’audio entrant avant de le lire ensuite au niveau du haut-parleur par la méthode play() précédente.
public void run(){

if(!detection) { // capture audio data
while(record) {
audioRecord.read(buffer, 0, bufferSize);
audioReceiver.audioReceive(buffer);
}
} else { // capture audio data in detection mode
while(record) {
while(!detectionBegin)
audioReceiver.audioDetectionBegin();
while(detectionBegin) {
audioReceiver.audioReceive(buffer);
}
audioReceiver.audioDetectionEnd();
}
}
audioRecord.stop();
}
Algorithme 9: capture de l'audio
IV.4.5. Le Multi langues

Android nous donne la possibilité d’adapter la langue de notre application à cette paramétré dans
le téléphone. Pour cela, il faut traduire toutes les variables du système contenues dans le fichier
res/values/ et créer pour chaque langue un répertoire res/values-xx/ où xx représente la langue
correspondante. Dans notre cas nous allons rendre notre application bilingue i.e. Anglais-Français.
Nous allons donc créer un répertoire res/values-en/ dans laquelle on va mettre toutes nos variables
traduites en anglais. Voici la méthode que nous avons défini pour le faire :

private void changeLanguage() {

if(D) Log.v(TAG, TAG+ " language changed to "+ param_language);
Locale locale = new Locale(param_language);
Locale.setDefault(locale);
Configuration config = new Configuration();
config.locale = locale;
getBaseContext().getResources().updateConfiguration(
config, this.getResources().getDisplayMetrics());
}
Algorithme 10: gestion du Multilingue
IV.5. BILAN DU CHAPITRE
Au cours du développement, nous avons été confronté à certaines difficultés liées au SDK
notamment concernant la gestion de la voix et du Bluetooth en particulier.
 Concernant l’Audio, la gestion du son encodé sur 8 bits nous a posé problème. Si de
nombreux projets semblent avoir été confrontés aux mêmes difficultés, rien d'officiel n'a été
reporté à ce sujet.
 Pour ce qui est de la gestion du Bluetooth, nous avons déterminé expérimentalement que la
taille maximal du buffer pouvant être envoyé par Bluetooth est de 357 ce qui était un vrai
problème quand il était question d’envoyer une longue conversation au destinataire. Pour
contourner ce problème, nous avons pensé à découper les paquets audio en des blocs de plus
petites tailles qui devaient être envoyés les uns à la suite des autres. En plus de cela, nous
avons remarqué que la fonction de connexion (connect()) arrivait parfois à passer sans
réellement établir la connexion avec le périphérique cible au niveau de l’application. Ce qui
nécessitait parfois un redémarrage complet du téléphone.
Vue que l’émulateur Android ne supporte pas la fonctionnalité Bluetooth, il a été très difficile
pour nous d’entrer en possession de deux périphériques physiques sur lesquelles nous devions faire
nos tests.

CHAPITRE V. VALIDATION DU PROTOCOLE

Plusieurs méthodes formelles de vérification et de validation des protocoles existent depuis des
dizaines d’années parmi lesquelles ProVerif [BBL 01] et AVISPA [AVI 06]. Nous avons choisi
pour la validation du protocole de routage que nous avons défini car il est au jour d’aujourd’hui
l’analyseur le plus connu et le plus abouti en matière de modélisation de protocoles (plus d’une
centaine de protocoles) [CHI 08]. Contrairement à ce que beaucoup de personnes viennent à penser,
AVISPA n’est pas seulement un outil fait pour la validation des protocoles de sécurités. Pour nous
rassurer du fait qu’AVISPA pouvait être utilisé pour la validation des protocoles de routage dans les
réseaux ad-hoc, nous somme entré en contact avec l’un des pionniers du projet AVISPA et actuel
directeur du projet AVANTSSAR1 nommé : Luca Vigano2 qui nous a redirigé vers plusieurs articles
traitants du sujet. Parmi ces articles, nous avons particulièrement apprécié celui de Davide Benetti,
« Model Checking Ad Hoc Network Routing Protocols » [DAV 10] où il fait une sorte de
benchmark entre plusieurs protocoles de routage dans les réseaux ad-hoc validés par AVISPA.
V.1. Présentation de la plateforme AVISPA
AVISPA (Automated Validation of Internet Security Protocols and Applications) est un outil de
validation formelle de protocoles. AVISPA dispose d’un langage de modélisation HPLS (High
Level Protocol Specification Language) qui permet le rapprocher la modélisation des protocoles à
au langage de base utilisé par les outils en arrière-plan. Comme la plupart de ces langages, les
langage de modélisation sont en général peu pratiques quand il s’agit de visualiser les résultats
produits. Dans le cas d’AVISPA, on a l’outil SPAN (Security Protocol ANimator for AVISPA)
[YAN 08] qui est l’une des outils développé par AVISPA pour rendre les choses plus accessibles au
grand public i.e. aux non-initiés. SPAN offre un environnement de simulation visuel plus convivial
où les résultats sont plus faciles à interpréter. La figure ci-dessous présente l’architecture
d’AVISPA.
1
www.avantssar.eu
2
Luca Vigano : (luca.vigano@univr.it)

D’après l’architecture ci-dessus, on voit bien qu’il y a quatre outils de vérification regroupés
dans AVISPA et ils utilisent tous des méthodes de vérification différentes. Ces outils sont OFMC
[LUC 05], CL-AtSe [TUR 06], SATMC [ALE 05] et TA4SP [YBO 05]. Nous nous attarderons
uniquement sur l’outil OFMC que nous allons utiliser dans nos simulations.
OFMC (On-the-Fly Model-Checker) exécute à la fois une falsification de protocole et une
vérification sur un nombre borné de sessions en explorant le système de transitions décrit par la
spécification IF (Intermediate Format), obtenue à partir de la spécification HLPSL à la volée.
L’efficacité du Backend OFMC est due à l’utilisation d’un certain nombre de techniques
symboliques à base de contraintes qui sont correctes et complètes dans le sens où aucune attaque
n’est perdue ou créée de toute pièce.
V.2. Les bases du langage HPLS
Il est facile de traduire un protocole en HPLS s’il est écrit suivant la notation Alice est Bob
appelé couramment notation A-B dans le jargon HPLS. Nous avons ajouté en ANNEXE A les
concepts de base du langage HPLS.
V.3. Modélisation de notre protocole de routage BRProtocol en langage

HPLS
Nous allons ici modéliser le cas d’une communication entre deux nœuds localisés dans deux
piconets différents i.e. ayant deux nœuds routeurs différents : Le nœud A veux communiquer avec
le nœud X dont il ne connait pas la position.
A
B C
Lorsque A envoi à son point d’accès B une demande de communication sous forme d’un message
unicast RREP1 de la forme (RREP, A, X, id, [ ]) où id est l’identifiant généré aléatoirement pour la
reconnaissance de l’accusé de réception et [ ] la chaine initialement vide des nœuds routeurs par
lesquelles sera passé le message. Lorsque B reçoit le message, il consulte sa table de routage et
constate que X n’est pas dans son rayon de portée. Il initie donc dans le réseau un message
broadcast RREQ2.
Il ajoute à ce message son adresse dans la chaine des nœuds initialement vide. Le message prend
donc la forme suivante : (RREQ, A, X, id, [B]). Lorsque le message arrive chez C, ce dernier
consulte vérifie si X est dans son rayon de portée. Puisque tel est le cas, il envoi cette foi un
message unicast à X pour lui informer que A veut communiquer avec en ajoutant évidement au
message dans la liste: (RREP, A, X, id, [B, C]). X répond favorablement à la demande de A en
envoyant un accusé de réception en utilisant le même canal par lequel est arrivée la demande de
communication de A. voici dans ce qui suit la représentation en notation A-B du langage HPLS à
quoi ressemble ce cas de communication.
1
Représentation en HPLS des messages unicast
2
Représentation en HPLS des messages broadcast

V.3.1. Notation A-B

A → B: RREP, A, X, id, [ ]
B → *: RREQ, A, X, id, [B]
C → X: RREP, A, X, id, [B,C]
X → C: {RREP, A, X, [B,C]}KX−
C → B: {{RREP, A, X, [B,C]}KX−}KC−
B → A: {{{RREP, A, X, [B,C]}KX−}KC−}KB−
V.3.1. Le rôle du nœud source

role source(
A,B,X : agent,
Ka, Kb, Kx : public_key,
RCV, SND : channel(dy))
played_by A def=
local
Rrep : protocol_id,
State : nat
const aa, bb, xx : protocol_id
init State := 2
transition
step1.
State = 2 /\ RCV({{Rrep.A'.X'.B'}_inv(Kx)}_inv(Kb))
/\ A' = A /\ B' = B
=|>
State':= 5 /\ wrequest(A,B,xx,X') /\ wrequest(A,B,bb,B')
/\ wrequest(A,B,aa,A')
end role
V.3.2. Le rôle du nœud routeur

role router (
A,B,X : agent,
RCV,SND : channel(dy))
played_by B def=
local
Rrep : protocol_id,
State : nat
init State := 1
transition
step1.
State = 1 /\ RCV({Rrep.A'.X'.B'}_inv(Kx))
/\ A' = A /\ B' = B /\ X' = X
=|>
State':= 4 /\ SND({{Rrep.A'.X'.B'}_inv(Kx)}_inv(Kb))
/\ wrequest(B,X,xx,X') /\ wrequest(B,X,bb,B')
/\ wrequest(B,X,aa,A') /\ witness(B,A,xx,X')
/\ witness(B,A,bb,B') /\ witness(B,A,aa,A')
end role

V.3.3. Rôle du nœud destinataire

role dest (
A,B,X : agent,
RCV,SND : channel(dy))
played_by X def=
local
Rrep : protocol_id,
State : nat
init State := 0
transition
step1.
State = 0 /\ RCV(start) /\ B' = B /\ X' = X
=|>
State':= 3 /\ SND({Rrep.A.X.B}_inv(Kx))
/\ witness(X,B,xx,X) /\ witness(X,B,bb,B)
/\ witness(X,B,aa,A)
end role
V.3.4. La session de communication

role session(
A,B,X : agent,
Ka, Kb, Kx : public_key)
def=
local
RCV1,SND1,RCV2,SND2,RCV3,SND3 : channel(dy)
composition
dest (A,B,X,Ka,Kb,Kx,RCV3,SND3)
/\ router (A,B,X,Ka,Kb,Kx,RCV2,SND2)
/\ source(A,B,X,Ka,Kb,Kx,RCV1,SND1)
end role
V.3.5. L’environnement de communication

role environment()
def=
const
aa, bb, xx : protocol_id,
a,b,x : agent,
ka,kb,kx : public_key
intruder_knowledge ={a,b,x,ka,kb,kx}
composition
session(a,b,x,ka,kb,kx)
/\ session(i,b,x,ka,kb,kx)
/\ session(a,i,x,ka,kb,kx)
/\ session(a,b,i,ka,kb,kx)
end role
goal
weak_authentication_on xx
weak_authentication_on bb
weak_authentication_on aa
end goal
environment()

V.4. Exécution sous AVISPA
Pour cela nous allons nous connecter à l’interface web d’AVISPA :
On va ensuite charger notre fichier que nous avons enregistré au format .hlpls. Ceci dans la
section User files et on va cliquer sur le bouton load file
Après avoir chargé le fichier, nous allons l’exécuter et faire une interprétation des résultats.
% OFMC
% Version of 2006/02/13
SUMMARY
SAFE
DETAILS
BOUNDED_NUMBER_OF_SESSIONS
PROTOCOL
C:\progra~1\SPAN\testsuite\results\BRPROTOCOL.if
GOAL
as_specified
BACKEND
OFMC
COMMENTS
STATISTICS
parseTime: 0.00s
searchTime: 0.03s
visitedNodes: 4 nodes
depth: 1 plies
Les résultats fournis ci-dessus sont ceux générés par le Backend OFMC qui montre que 4 nœuds
ont été parcourus avec un tems de recherche de 0.03 secondes.

V.5. Simulation avec l’outil SPAN :
On charge notre fichier BRProtocol_ok.hlpsl et on lance la simulation
Ce qui nous renvoi à la fenêtre suivante :
Ensuite on exécute les différents scénarios proposés par SPAN, pour obtenir le résultat suivant :
S’ensuit alors l’échange des messages entre les deux nœuds :

Dans cette simulation nous avons 7 nœuds dont deux nœuds sources (a-3, a-8), deux nœuds
destinations (x-6, x11) et trois nœuds routeurs (b-4, c-5, c-10). Le scénario d’exécution concerne les
nœuds a-3, b-4, c-10 et x-11. Dans ce scénario, a-3 veut communiquer avec x-11. Il initie une
demande de communication à son nœud routeur qui est b-4 qui achemine la demande vers c-10 qui
est le nœud routeur de x-11. On constate bien qu’en 6 étapes a-3 réçoit l’accusé de reception de x-
11. Les deux nœuds peuvent ainsi utiliser le même canal de communication pour echanger les
messages vocaux.
V.6. BILAN
D’après les résultats fournis par la simulation sur AVISPA et sur SPAN (0.03 secondes) pour la
recherche du nœud destinataire avec l’intervention de 2 nœuds routeurs, nous pouvons dire que
notre protocoles répond bien aux exigences de temps de communication qui doit être le plus court
possible. En plus on a pu constater que les échanges en effectivement faites entre chaque nœud
mobile et son nœud routeur.

CONCLUSION GENERALE
La problématique de l’intégration de la voix dans les réseaux sans fils comme le Bluetooth est
liée à plusieurs contraintes relatives au transfère synchrone et en temps réel des données entre les
différents nœuds en communication. Dans la première partie de ce mémoire, après avoir défini le
contexte et la problématique de notre travaille, nous avons présenté nos motivations et les divers
enjeux de la solution que nous avons proposé. S’en est suivi les différents domaines dans lesquels
notre solution pouvait être appliquée.
Notre principal objectif étant de proposer une solution efficace de téléphonie dans les réseaux
Bluetooth, nous avons commencé par étudier dans la deuxième partie de notre travail les divers
travaux qui avaient déjà été menés dans ce sens en faisant le tour des autres technologies de
communication sans fil existantes comme le GSM, le Wifi avec la VoIP et les différentes solutions
existantes avec le Bluetooth. Nous avons vu que ces solutions étaient jusqu’ici peut adaptées au
contexte socio-économique des pays en voie de développement comme le Cameroun qui faisaient
l’objet de notre attention.
C’est alors que nous avons pensé à concevoir dans la troisième partie de notre travail une
nouvelle solution qui permettrait de briser les barrières posées par la faible portée du Bluetooth qui
est limitée à une distance de 100 mètres pour les émetteurs de classe 1. Cela nous a emmené à
définir de nouveaux concepts comme les nœuds routeurs qui jouent un rôle centrale dans notre
architecture finale. Notre solution étant basée sur un concept novateur, nous étions contraint de
définir un nouveau protocole de routage basé principalement sur les protocoles B.A.T.M.A.N.
[AXE 07] et ZRP [NIC 01] et un protocole de formation de scatternet basé sur le protocole BTCP
[SAL 01]. Ce qui a d’ailleurs value une publication [NON 12] dans la conférence internationale
AFRICOMM édition 2012 où nous avons défendu les différents concepts que notre solution
apportait dans le domaine scientifique.
Nous avons dans la phase de mise en œuvre développé une application de communication entre
deux périphériques Bluetooth tournant sur la plateforme Android et basé sur le langage java. Afin
de valider nos différents protocoles, nous avons utilisé l’outil AVISPA avec son simulateur SPAN
qui a prouvé son efficacité de par le monde.

PERSPECTIVES
Le travail que nous avons mené donne lieu à plusieurs ouvertures dans le domaine scientifique.
Nous proposons dans les travaux futurs de concevoir et de réaliser notre nœud routeur comme un
périphérique à part entière afin de répondre aux problèmes de routage et de qualité de service dans
les réseaux Bluetooth un peu comme les points d’accès dans les réseaux Wifi. Cela pourrait
permettre d’implémenter notre protocole de routage sans avoir recourt à d’autres équipements tiers
comme les machines serveurs et autres hub et clés Bluetooth qui sont pour le moment les principaux
constituants de notre nœud routeur. Ceci pourra constituer une amélioration considérable dans le
fonctionnement des réseaux ad-hoc car ils seraient alors en mesure de disposer de la notion
d’infrastructures dans la mesure où les nœuds routeurs sont censés être fixes.
Bien qu’ayant limité au maximum les émissions des paquets entres les différents nœuds dans
notre protocole de routage, nous proposons aussi une gestion plus efficace de la consommation en
énergie dans notre réseau. L’aspect sécurité ne saurait être négligé : bien que le Bluetooth offre déjà
un mécanisme d’authentification entre les différents périphériques, les communications restent
toujours vulnérables à diverses attaques de toute sorte. La conversation entre deux utilisateurs est
susceptible d’être intercepté par un périphérique tiers utilisant l’une des applications de hacking des
réseaux Bluetooth disponibles gratuitement en ligne.
En ce qui concerne l’aspect développement, nous avons rencontré plusieurs difficultés avec le
SDK d’Android notamment concernant la gestion de la voix et du Bluetooth. C’est pourquoi nous
préconisons pour les futurs travaux l’utilisation du NDK Android qui offre beaucoup plus de facilité
et d’outils que le SDK.
Avec de telles améliorations il serait possible de mettre sur pied une plateforme complète de
téléphonie basé sur le Bluetooth et ouverte à d’autres technologies.
PUBLICATION SCIENTIFIQUE
Articles de conférences internationales avec actes et comité de lecture
- NONO LOUENKAM Guy Gaspard, Thomas DJOTIO NDIE, An approach of making

telephony in a local wireless environment: application to Bluetooth technology. Yaoundé:
AFRICOMM (November 2012).

ANNEXE A : LES BASES DU LANGAGE HPLS

Définition des rôles
Lors de la modélisation d’un protocole, il est important de faire une brève présentation du flow de
données qui circule entre les différents participants dans le réseau et de définir les différents rôles de base à
jouer par chacun d’eux. Pour chacun des rôles il y aura un ensemble d’action basic spécifique pour une
séquence d’action. Un même rôle peut être jouer par un ou plusieurs participant dans le protocole.
Notons que les noms des rôles commencent toujours par une lettre minuscule. Et la dénotation des agents
jouant un rôle est en générale marquée par une lettre majuscule comme A dans le cas d’Alice et B pour bob.
La définition de chaque rôle de base décrit l’ensemble d’informations nécessaires pour un participant devant
jouer ce rôle. Nous pouvons citer :
 les paramètres (parameters),
 l’état initial du rôle,
 les états de transition du rôle (transition).
Voici un exemple pour le rôle « alice » dans le protocole simple d’échange de clé :
role alice(
A,B,S : agent, Kas : symmetric_key, SND, RCV : channel (dy))
played_by A def=
local State : nat,
Kab : symmetric_key
init State := 0
transition
...
end role
A, B et S sont des paramètres de type agent, Kas est un paramètre de type symmetric_key, et les
paramètres SND et RCV qui sont de type channel. Ces deux derniers paramètres définissent les canaux de
communication entre les différents agents devant jouer le rôle « alice » notamment A, B et C. le type du
canal prend un attribut supplémentaire (dy) qui définit le modèle d’intrus représenté pour ce canal de
communication. (dy) ici désigne le modèle d’intrus Dolev-Yao [DOL 83]. Lorsqu’on précise ce paramètre
c’est pour éviter toute intrusion dans le système. Etant fixé à (dy) dans notre cas, toute intrusion en dessous
de ce modèle pourra intercepter et même modifier tous les messages échangés par les agents par ce canal. On
définit en général un intrus dans le système pour simuler les cas d’attaque du réseau et tester le niveau de
sécurité du protocole.
La section played_by où apparait l’agent "A" montre que "A" jouera par défaut le rôle « alice ». La
section local permet de déclarer les variable locales au rôle « alice ». dans notre cas on a deux variables
locales : State de type nat (entier naturel) et Kab de type symetric_key. La variable State a comme valeur par
défaut 0. Cette variable est présente dans pratiquement tous les rôles définis en HPLS.
Toute variable en HPLS commence par une lettre majuscule et toute constante par une lettre minuscule.
Néanmoins, toutes les constantes de même que les variables sont typées.
Transitions
La section des transitions de HPLS représente en générale les échanges de messages entre un expéditeur
et un destinataire. La première étape consiste le plus souvent à la réception d’un message et la seconde à la
réponse à un message reçu. Les transitions sont définies par des déclencheurs ou pré-condition suivi des
différentes actions à exécuter lorsque survient chacune d’elle.
Voici un exemple de définition d’état de transition en HPLS.

step1. State = 0 /\ RCV({Kab’}_Kas) =|>

State’:= 2 /\ SND({Kab’}_Kbs)
Cette transition appelé step1 qui permet de la distinguer d’autres transitions permet de définir que lorsque
la valeur de la variable State est à 0 est qu’un message est reçu du canal RCV contenant la clé Kab’ crypté
avec Kas, alors step1 va mettre à jour la valeur de la variable State à 2 et va envoyer un message par le
canal SND la valeur reçu précédemment (Kab’) en la cryptant avec Kbs. On peut remarquer que lorsque la
valeur de la variable State change elle est notée avec un prime : State’. Il faut également noter que tant que
la transition n’est pas complète, la valeur de cette variable ne changera pas. Avec la transition on peut donc
compléter notre rôle de base comme suit :
role alice(
A,B,S : agent, Kas : symmetric_key, SND, RCV : channel (dy))
played_by A def=
local State : nat,
Kab : symmetric_key
init State := 0
transition
step1. State = 0 /\ RCV({Kab’}_Kas) =|> State’:= 2 /\ SND({Kab’}_Kbs)
end role
Les rôles composés

Les rôles composés instancient un ou plusieurs rôles de base. Ils permettent en fait d’associer plusieurs
rôles entre eux de façon à les exécuter ensemble (en parallèle en générale). Pour mieux expliquer en quoi
consiste les rôles composés nous allons supposer que nous avons défini deux autres rôles de base ne plus du
rôle « alice », notamment, le rôle « bob » et le rôle « server ». Avec ces trois différents rôles nous pouvons
définir un rôle nommé session, composé de ces trois rôles de base.
role session( A,B,S : agent, Kas, Kbs : symmetric_key)
def=
local SA, RA, SB, RB, SS, RS: channel (dy)
composition
alice (A, B, S, Kas, SA, RA)
/\ bob (B, A, S, Kbs, SB, RB)
/\ server(S, A, B, Kas, Kbs, SS, RS)
end role
Les rôles de base n’ont pas de section de transition mais plutôt une section de composition. L’opérateur
/\ montre que les différents rôles doivent être exécuté en parallèle. Les variables du rôle composé ne sont rien
d’autre que l’ensemble des variables de chacun des rôles de base qui le compose.
L’environnement du système
On peut après avoir défini les sessions comme étant des rôles composés définir un autre rôle composé :
l’environnement qui peut contenir plusieurs sessions. Ce rôle est en fait le rôle de plus haut niveau du
système.

role environment()
def=
const a, b, s : agent,
kas, kbs, kis : symmetric_key
intruder_knowledge = {a, b, s, kis}
composition
session(a,b,s,kas,kbs)
/\ session(a,i,s,kas,kis)
/\ session(i,b,s,kis,kbs)
end role %fin du role
C’est également dans ce rôle qu’on définit les propriétés de l’intrus du système avec l’ensemble des
informations qu’il possède à l’avance notamment, les noms de tous les agents, toutes les clés publique du
système, sa propre clé privé qu’il partage avec tous les autres agents et aussi toutes les fonctions publiques
du système. La constante i dans notre cas défini l’intrus de notre système.
ANNEXE B : PREUVES DES RELATIONS (1) ET (2)

Preuve de la relation (1) :
�
�= , 1 ≤ K ≤ 7, 1 ≤ N ≤ 36. Relation 3: Nombre de piconet
�
Où N est le nombre de Nœud routeur en compétition, K le nombre de nœud esclave par piconet et
.
Nous voulons montrer qu’un scatternet de n équipements peut avoir au moins (n-1)/k piconets.
Pour cela, considérons k+1 le nombre max de nœud dans un piconet et p(n) le nombre minimum de piconet
pour un scatternet.
Nous allons montrer que p(n) ≥ (n −1)/k par récurrence sur p(n).
Premièrement, si p(n)=1, alors partant de p(n) ≥ (n −1)/k, on a :
1≥ (n −1)/k
==> k > n-1
==> n ≤ k +1 c’est-à-dire dans un piconet on a au plus k+1=8 nœuds ce qui est vrai.
Par hypothèse, chaque piconet peut avoir au plus k+1 nœuds.
Supposons l’hypothèse vrai à l’ordre m c’est-à-dire que si p(n) ≤ m, alors p(n) ≥ (n −1)/k et montrons qu’elle
reste vrai à l’ordre m+1.
Considérons le cas p (n')=m+1. Etant donné un scatternet de n' dispositifs, choisissons au hasard un piconet
et supprimons son maître et k-1 de ses esclaves laissant celui qui servait de connexion au scatternet ce qui
fait k éléments supprimés. Après la suppression de ce piconet, on se retrouve avec un scatternet formé de n'-
k éléments.
Par hypothèse de récurrence, on a p(n) ≥ (n −1)/k si p(n) ≤ m. puisque n ≥ n'−k, on a
p(n) ≥ (n'−k−1)/k = (n−1)/k−1. Ainsi, p (n') ≥ p(n) +1 ≥ (n'−1)/k.
Preuve de la relation (2) :

� �
�= , où P est le nombre de Relation 4: nombre de nœud de relai
piconet.
2 piconet ne peuvent partager plus d’un pont.

Cette relation est une relation de recurence sur le nombre de piconet.

Cette relation peut encore tout simplement s’exprimer : B(p)=1+2+3+…+p-1
Pour p=1 on a 0 nœud pont
Pour p=2 on a 1 nœud pont
Pour p=3 on a 3 nœuds pont
…
Pour p=n on
ANNEXE C : PRESENTATION DE LA PLATE-FORME

ANDROID
Caractéristiques :
Android est un système d’exploitation basé sur le noyau linux. Il utilise une machine virtuelle
personnalisée conçu pour optimiser l’utilisation de la mémoire et des ressources matérielle d’un appareil
mobile. Android a été conçu pour intégrer au mieux des applications existantes de Google comme le service
de courrier Gmail, celui de la cartographie, Google Maps, ou encore Google Agenda, Google Talk, YouTube
et bien d’autres. Il existe de nombreux sites, blogs et forums, professionnels ou amateurs, traitant du
développement sur Android. Sa documentation officielle se trouve sur http://www.android.com/.
Particularité :
Android permet aux développeurs de bénéficier au maximum de tout ce que peut offrir un appareil
mobile. Ainsi, une application Android peut accéder à toutes les fonctionnalités du téléphone comme lancer
un appel, accéder aux répertoires du téléphone, envoyer des SMS, des emails, des MMS, utiliser le GPS, ou
la camera (appareil photo) intégré du téléphone, utiliser le Bluetooth, le wifi et bien d’autres. Cette facilité
d’accès aux fonctionnalités du téléphone permet au développeur de créer des applications plus riches.
Environnement de développement :
Le développement des applications (spécifiques à la téléphonie mobile) sur Android nécessite un kit de
développement : le SDK dont la dernière version (android-sdk_r20.0.3-windows) est téléchargeable
gratuitement sur le portail des développeurs d’Android « http://developer.android.com/ ». Le
développement d ’applications Android est possible aussi bien sur Eclipse, que sur Apache Ant ou
JDK ou sur NetBeans . C’est pourquoi il est possible aussi bien sur Windows que sur Linux ou sur
MacOs.
Emulateur Android :
Le SDK intègre un simulateur d’environnement d’exécution
reproduisant sur la machine du développeur le comportement du
téléphone et lui permettant de tester le fonctionnement de son
application sur un terminal virtuel. Cependant, les simulateurs ont
des fonctionnalités moindres par rapport à un vrai terminal. Nous
pouvons citer entre autres la gestion des capteurs sensoriels
(accéléromètre, température, odeur…), du Bluetooth, du wifi. A
chaque version d’Android est associée une version de l
Figure 22: exemple d'émulateur
’émulateur, permettant au développeur de voir exactement à quoi
ressemblera son application sur un matériel réel. L’émulateur est téléchargeable via le SDK Manager dont
la dernière version actuellement disponible est Android-4.1.
Langages de développement sous Android:
Java est le principal langage utilisé pour le développement d’applications Android. Néanmoins, des
extensions permettent de développer des applications en utilisant le langage C natif. Mais ceci nécessite un
travail plus important au niveau de la portabilité.
Android Market:

Android est en constante évolution grâce au dynamisme des développeurs qui réalisent chaque jour des
applications innovantes. Android permet de rendre disponibles les applications aux utilisateurs finaux
via une plate-forme de téléchargement . Android propose la plate -forme Android Market pour la
publication des applications. Notons qu’a l’heure actuelle, il y a environ 50000 applications sur
l’Android Market « http://www.android.com/market/ ». Pour publier une application sur l ’Android
Market, il faut s’inscrire sur le site en question et payer des frais d’inscription de 25$
« http://market.android.com/publish/signup ».
Achitecture de la plateforme Android :
Le diagramme suivant illustre les composants principaux du système d’exploitation Android.
Figure 23: Architecture interne d ’Android
Brève Description des différentes couches de l’architecture

Applications Android est fourni avec un ensemble d’applications dont un client email, une application
SMS, un calendrier, un service de cartographie, un navigateur… toutes écrites en JAVA.
Framework de développement En fournissant une plateforme de développement ouverte, Android
offre aux développeurs la possibilité de créer des applications extrêmement riches et innovantes. Les
développeurs ont un accès complet au même Framework API utilisé par les applications de base.
Bibliothèques Android dispose d’un ensemble de librairies C/C++ utilisées par les différents composants
du système Android. Elles sont offertes aux développeurs à travers le Framework Android.
Android Runtime Android inclut un ensemble de librairies de base offrant la plupart des fonctionnalités
disponibles dans les bibliothèques de base du langage de programmation Java. Chaque application Android
s’exécute dans son propre processus, avec sa propre instance de la machine virtuelle Dalvik. Dalvik a été
écrit pour que le dispositif puisse faire tourner plusieurs machines virtuelles de manière efficace.
Linux Kernel Android est basé sur un kernel linux 2.6.xx mais ce n'est pas linux. Il ne possède pas de
système de fenêtrage natif (X window system). La machine virtuelle Dalvik s’appuie sur le noyau Linux
pour les fonctionnalités de base telles que le filetage et la gestion de la mémoire de bas niveau.

REFERENCES BIBLIOGRAPHIQUES
 [AGG 00] Aggarwal Alok Manika Kapoor, et al. Clustering algorithms for wireless ad-hoc network [Article] //
The 4th International Workshop on Discret Algorithm and Methods For Mobile Computing and
Communication. - 2000. - pp. 54-63.
 [ALE 05] Alessandro Armando Luca Compagna, An optimized intruder model for sat-based model-checking
of security protocols. [Revue]. - [s.l.] : Electr. Notes Theor. Comput. Sci, 2005. - Vol. 125(1). - pp. 91–108.
 [ANE 02] Anelise Munaretto Hakim Badis, Khaldoun Al Agha, Guy Pujolle A Link-state QoS Routing Protocol
for Ad Hoc Networks [Rapport] / LRI Laboratory ; University of Paris XI. - Paris : INRIA, 2002. -
http://www.lri.fr/~alagha/OPNET/OLSR.pdf. - 0-7803-7605-6/02/$17.00-2002 IEEE.
 [ANN 06] Anna Forster Machine Learning Techniques Applied to Wireless Ad-Hoc Networks: Guide and
Survey [Rapport] / University of Lugano, Switzerland. - Lugano : University of Lugano, Switzerland, 2006. -
https://docs.google.com/viewer?url=http://www.dti.supsi.ch/~afoerste/publications/survey_issnip.pdf.
 [AVI 06] AVISPA Team AVISPA v1.1 User Manual [Rapport] / IST. - Europe : Information Society Technologies
Programme, 2006.
 [AXE 07] Axel Neumann Corinna Elektra Aichele, Marek Lindner B.A.T.M.A.N Status Report [Rapport]. -
2007. - http: //open-mesh.net/batman.
 [BAD 06] BADIS HAKIM ÉTUDE ET CONCEPTION D’ALGORITHMES POUR LES RÉSEAUX MOBILES ET AD HOC
[Ouvrage]. - Université de Paris-Sud : THESE DE DOCTORAT, 2006.
 [BBL 01] B. Blanchet An efficient cryptographic protocol verifier [Revue] // P o eedi gs of CSF’ .. - [s.l.] :
IEEE Computer Society Press,, 2001. - pp. 82-96.
 [BLU 03] Bluetooth Specification Adaptation RFCOMM with TS 07.10 - serial port emulation [Ouvrage]. -
2003. -
http://www.google.cm/url?sa=t&rct=j&q=rfcomm%20pdf&source=web&cd=1&ved=0CFAQFjAA&url=http%3
A%2F%2Fwww.bluetooth.org%2Fdocman%2Fhandlers%2FDownloadDoc.ashx%3Fdoc_id%3D40909&ei=SfjyT
4_bLo26hAfE8eTPCQ&usg=AFQjCNFkXrsvbbpIPQG-_FJUXM3RjcbiqQ&cad=rja.
 [BOU 11] BOURDIEU C. F. CADIEU,Matthieu HOURDEBAIGT,Sébastien NAHELOU Logiciel de type talkie-
walkie sur terminaux mobiles Android, Projet de programmation INF466 [Ouvrage]. - Bordeaux : Université
de Bordeaux1 Science Technologie, 2011.
 [CHI 02] Ching Law Amar k. Mehta, Kai-Yeung siu A new New Bluetooth Scatternet Formation Protocol
[Rapport] / Massachusetts Institut of Technologie. - Massachusetts : Auto ID Center, 2002. - p. 29.
 [CHI 08] Chita Christian MAIDS for VoIP: A Mobile Agents-based Intrusion Detection System for Voice over
Internet Protocol [Rapport] / The Faculty of Graduate Studies (Computer Science) ; THE UNIVERSITY OF
BRISTISH COLUMBIA. - Vancouver) : [s.n.], 2008.
 [DAV 00] Dave Suvak IrDA and Bluetooth: A Complementary Comparison [Rapport]. - [s.l.] : Extended
Systems, Inc, 2000.
 [DAV 10] Davide Benetti Massimo Merro, Luca Vigano, Model Checking Ad Hoc Network Routing Protocols:
ARAN vs. endairA [Revue] // Proceedings of SEFM 2010. - 2010. - pp. 191–202.
 [DEL 06] Delmas Julien Les relais GSM [Ouvrage]. - California : Creative Commons, 2006. - Vol. I. -
http://lesrelaisgsm.juliendelmas.com.
 [DJO 10] Thomas DJOTIO NDIE cours Reseaux Avance Master 2 [Ouvrage]. - UNIV de Yaoundé 1 : [s.n.], 2010.
 [DOL 83] Dolev D. A. Yao. On the Security of Public-Key Protocols [Rapport]. - [s.l.] : IEEE Transactions on
Information Theory,, 1983..
 [ENC 09] Encarta et Encyclopedie Herschel, sir William [Rapport]. - [s.l.] : Microsoft Corporation, 2009.
 [FAB 11] Fabien Chéreau Jocelyn Viallon, Oscar Arturo, Philippe Dumoulin, Tangui Morlier, Thomas Petit Le
protocole Bluetooth [En ligne] // Bluetooth et les technologies associé. - Département Informatique de l'INSA
de Lyon, 06 2011. - 14 06 2012. - http://tp.bluetooth.free.fr/protocol.html.
 [FEN 08] FENG GAO MARTIN HOPE Collaborative Middleware on Symbian OS via Bluetooth MANET
[Article] // WSEAS TRANSACTIONS on COMMUNICATIONS / éd. Informatics Research Institute the University
of Salford. - April 2008. - ISSN: 1109-2742. - 4 : Vol. 7. - pp. 300-310. - http://www.wseas.us/e-
library/transactions/communications/2008/25-692.pdf.
 [GRY 01] Gryazin Eugene A. Service Discovery in Bluetooth [Rapport] / Department of Computer Science,
Group for Robotics and Virtual Reality ; Helsinki University of Technology. - Helsinki : [s.n.], 2001. - p. 4. -
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.33.5247&rep=rep1&type=pdf.

 [GUI 10] Guillaume Faure Maxime Raoust Developpement d'une application de communication Bluetooth
sur Android [Rapport] : Projet de fin d'étude / TELECOM ; TELCOM Sud-Paris. - Sud-Paris : TELCOM Sud-Paris,
2010. - http://gou1-sandbox.googlecode.com/files/Rapport%20projet%20ASR%20-
%20Faure%20et%20Raoust.pdf.
 [GUO 03] Guoyou He Destination-Sequenced Distance Vector (DSDV) Protocol [Rapport] / Networking
Laboratory ; Helsinki University of Technology . - Helsinki : [s.n.], 2003. -
http://www.netlab.tkk.fi/opetus/s38030/k02/Papers/03-Guoyou.pdf.
 [GUY 06] Guy Pujolle Les Reseaux [Ouvrage]. - [s.l.] : Eyrolles, 2006. - 5eme : p. 562. - http://www.editions-
vm.com/Chapitres/9782212119879/Chap21_Pujolle.pdf. - ISBN - 2-212-1 1987-9.
 [ICU 03] ICU Bluetooth Packets [Rapport] / Multimedia Laboratory ; Information and Communication
University. - Korea : Special Topics on Ad-hoc and Sensor Networks, 2003. -
http://mmlab.kaist.ac.kr/menu2/popup/ICE839/Bluetooth-2.pdf.
 [IEE 99] IEEE LAN/MAN Standards Committee of IEEE Computer Society Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY)specifications: Higher-Speed Physical Layer Extension in the 2.4 GHz
Band [Ouvrage] = IEEE Std 802.11b-1999. - New York : The Institute of Electrical and Electronics Engineers,
Inc., 1999. - http://standards.ieee.org/getieee802/download/802.11b-1999.pdf.
 [IEEf 03] IEEE LAN-MAN Standards Committee of the IEEE Computer Society [Ouvrage] = IEEE 802.11f
Standart. - New York : 802.11 IEEE Standard for Information technology, inc, 2003. -
http://standards.ieee.org/getieee802/download/802.11F-2003.pdf.
 [IEEg 03] IEEE LAN-MAN Standards Committee of the IEEE Computer Society [Ouvrage] = IEEE Std 802.11g. -
New York : 802.11 IEEE Standard for Information technology, inc, 2003. -
http://pdos.csail.mit.edu/decouto/papers/802.11g.pdf.
 [IEEd 01] IEEE LAN-MAN Standards Committee of the IEEE Computer Society 802.11 IEEE Standard
[Ouvrage] = IEEE Std 802.11d. - NY : [s.n.], 2001. - http://standards.ieee.org/getieee802/download/802.11d-
2001.pdf.
 [IEEh 03] IEEE LAN-MAN Standards Committee of the IEEE Computer Society IEEE 802.11h Standart
[Ouvrage] = IEEE 802.11h Standart. - New York : 802.11 IEEE Standard for Information technology, inc, 2003. -
http://standards.ieee.org/getieee802/download/802.11h-2003.pdf.
 [IEEe 05] IEEE LAN-MAN Standards Committee of the IEEE Computer Society Part 11: Wireless LAN Medium
Access Control (MAC) and PhysicalLayer (PHY) specifications Amendment 8: Medium Access Control (MAC)
Quality of Service Enhancements [Ouvrage] = IEEE 802.11e Standart. - New York : 802.11 IEEE Standard for
Information technology, inc, 2005. - http://standards.ieee.org/getieee802/download/802.11e-2005.pdf.
 [IEEk 08] IEEE LAN-MAN Standards Committee of the IEEE Computer Society Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 1: Radio Resource Measurement of
Wireless LANs [Ouvrage] = IEEE std 802.11k. - New York : 802.11 IEEE Standard for Information technology,
inc, 2008. - http://www.cs.clemson.edu/~jmarty/courses/papers/wireless/wifi/802.11k-2008.pdf.
 [IEE-D 04] IEEE LAN-MAN Standards Committee of the IEEE Computer Society Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) specifications Amendment 3: Specification for operation in
additional regulatory domains [Ouvrage] = IEEE Std 802.1D. - New York, : IEEE Standard for Information
technology, 2004. - http://standards.ieee.org/getieee802/download/802.1D-2004.pdf.
 [IEEn 09] IEEE LAN-MAN Standards Committee of the IEEE Computer Society Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) specifications Amendment 5: Enhancements for higher
throughput [Ouvrage] = IEEE std 802.11n. - New york : 802.11 IEEE Standard for Information technology, inc,
2009. - http://standards.ieee.org/getieee802/download/802.11n-2009.pdf.
 [IEEi 04] IEEE LAN-MAN Standards Committee of the IEEE Computer Society Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) specifications Amendment 6: Medium Access Control (MAC)
Security Enhancements [Ouvrage] = IEEE 802.11i Standart. - New York : 802.11 IEEE Standard for Information
technology, inc, 2004.
 [IEEj 04] IEEE LAN-MAN Standards Committee of the IEEE Computer Society Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) specifications Amendment 7: 4.9 GHz–5 GHz Operation in
Japan [Ouvrage] = IEEE std 802.11j. - New York : 802.11 IEEE Standard for Information technology, inc, 2004. -
http://standards.ieee.org/getieee802/download/802.11j-2004.pdf.
 [IEEs 06] Joseph D. Camp Edward W. Knightly IEEE 802.11s Extended Service Set Mesh Networking Standard
[Revue]. - Houston : Electrical and Computer Engineering, Rice University, Houston, TX, 2006. -
http://networks.rice.edu/papers/mesh80211s.pdf.
 [LUC 05] Luca Vigano David A. Basin, Sebastian Modersheim, Ofmc : A symbolic model checker for security
protocols [Revue] // Int.J. Inf. Sec.,. - 2005. - pp. 181–208,.

 [MAH 06] Mahesh K. Marina Samir R. Das Ad hoc on-demand multipath distance vector routing [Rapport] /
Computer Science Department ; University of California, Los Angeles. - Los Angeles : Wiley InterScience,
2006. - pp. 969–988. - http://homepages.inf.ed.ac.uk/mmarina/papers/wcmc06.pdf. - ANI-0308631.
 [MAR 01] Martin De wulf Memoire de Master, Un logiciel d'illustration des protocoles GSM et GPRS sur la
voie radio [Ouvrage]. - Rue Grandgagnage, France : Facultés Universitaires Notre-Dame de la Paix, 2001.
 MP3 streaming over Bluetooth to multiple users [Revue].
 [CHI 08] Chikouche M. Benmohammed V ifi atio auto ati ue des p oto oles d’authe tifi atio des
systèmes [Rapport] / D pa te e t d’i fo ati ue ; U i e sit de M’sila, U i e sit de Constantine. -
Algérie : [s.n.], 2008.
 [NEI 10] Neil Tebbutt John Prince, Pietro Capretta Bluetooth 3.0 High-Speed versus Wi-Fi Direct [Ouvrage]. -
2010.
 [NIC 01] Nicklas Beijar Zone Routing Protocol (ZRP) [Rapport] = ZRP / Networking Laboratory ; Helsinki
University of Technology. - Helsinki : [s.n.], 2001. - p. 12. -
http://www.netlab.tkk.fi/opetus/s38030/k02/Papers/08-Nicklas.pdf.
 [NON 12] NONO LOUENKAM G. Thomas DJOTIO NDIÉ An approach of making telephony in a local wireless
environment: application to Bluetooth technology [Rapport]. - Yaounde : AFRICOMM, 2012. - AFRICOMM-
135274696582691.
 [PAS 05] Pascal Ciurlik Nicolas Engrand, Sébastien Marszalek, Xavier Okoué Wifi et Bluetooth [Ouvrage]. -
France : Miage, USTL, 2005. - http://sciences-de-la-terre.univ-
lille1.fr/digitalAssets/8/8543_Bluetooth_wifi.pdf.
 [PIN 11] pingoa [En ligne] // www.frandroid.com. - 06 09 2011. - 24 02 2012. -
http://forum.frandroid.com/topic/70131-tuto-le-wi-fi-direct-cest-possible/.
 [RAB 04] Rabih MOAWAD QoS dans les WPAN, WLAN et WMAN [Rapport] : MEMOIRE DE DEA /
Departement d'informatique ; UNIVERSITE AUF LIBANAISE SAINT JOSEPH. - Beyrouth : UNIVERSITE AUF
LIBANAISE SAINT JOSEPH, 2004. - p. 64. - http://www.lb.refer.org/memoires/560895RabihMOAWAD.pdf.
 [RFC 96] RFC H. Schulzrinne,et al RTP: A Transport Protocol for Real-Time Applications [Ouvrage] = rfc1889 -
RTP. - Berkeley : Request for Comments: 1889, 1996. - http://www.ietf.org/rfc/rfc1889.txt. - rfc1889.
 [ROB 05] Robert M. Gray The 1974 Origins of VoIP [Rapport]. - [s.l.] : IEEE SIGNAL PROCESSING MAGAZINE,
2005. - http://www.cspl.umd.edu/spm/cfp/September-06.pdf.
 [SAL 01] Salonidis Theodoros Pravin Bhagwat, Leandros Tassiulas, and Richard LaMaire Distributed topology
construction of Bluetooth personal area networks [Rapport] / Electrical and Computer Engineering
Department ; University of Maryland at College Park. - Maryland : In Proceedings of the Twentieth Annual
Joint Conference of the IEEE Computer and Communications Societies, 2001. - p. 10. -
http://www.thlab.net/~thsalon/papers/BTCP_JSAC05.pdf. - BTCP_JSAC05.
 [SIG 10a] SIG BLUETOOTH SPECIFICATION [Rapport]. - Europe, Japan, USA, Canada : Bluetooth SIG, 2010. -
http://developer.bluetooth.org/KnowledgeCenter/TechnologyOverview/Documents/Core_SPEC.pdf. - IEEE

802.15.
[SIG 10b] SIG BLUETOOTH SPECIFICATION [Rapport]. - Europe, Japan, USA, Canada : Bluetooth SIG, 2010,
209-253. -
http://developer.bluetooth.org/KnowledgeCenter/TechnologyOverview/Documents/Core_SPEC.pdf. - IEEE
802.15.
 [SIG 10c] SIG BLUETOOTH SPECIFICATION [Rapport]. - Europe, Japan, USA, Canada : Bluetooth SIG, 2010,
746. - http://developer.bluetooth.org/KnowledgeCenter/TechnologyOverview/Documents/Core_SPEC.pdf. -
IEEE 802.15.
 [SIG 01] SIG Bluetooth, Part F:3 TELEPHONY CONTROL PROTOCOL SPECIFICATION TCS Binar [Section] //
Specification of the Bluetooth System v1.1 / auteur du livre Bluetooth SIG. - USA : [s.n.], 2001, 444-570. -
http://www.m2mgsm.com/download/BT/docs/descr2/TCSBinary.pdf.
 [SIN 05] Singh Mritunjay MP3 streaming over Bluetooth to multiple users [Rapport] / Tata Consultancy
Services, Clarinox Technologies. - Australia : TCS/Clarinox, 2005, p2. -
http://www.clarinox.com/docs/whitepapers/Whitepaper_05_MP3.pdf.
 [SST 06a] SST Service pour la Science et la technologie La voix sur IP et le Wifi : genèse d'une technologie née
en Israël [Rapport] / Service pour la Science & la Technologie ; Ambassade de France en Israël. - Tel Aviv
63801 - ISRAËL : Republique Francaise, 2006, p3. - www.fitscience.org.
 [SST 06b] SST Service pour la Science et la technologie La voix sur IP et le Wifi : genèse d'une technologie
née en Israël [Rapport] / Service pour la Science & la Technologie ; Ambassade de France en Israël. - Tel Aviv
63801 - ISRAËL : Republique Francaise, 2006. - www.fitscience.org.

 [STE 05] Steve Brar al Dynamic Bluetooth File Sharing With Cellular Devices [Ouvrage]. – 2005, p5. -
http://www.ece.ucdavis.edu/~chuah/classes/eec173B/eec173b-w06/project/bluetooth-sharing.pdf.
 [SYS 10] System cisco Téléphone mobile WiFi élégant et complet pour service de téléphonie sur IP
[Rapport]. - 2010.
 [TRA 09] TRAN Quoc Tuan Protocoles de routage dans les réseaux multi-radios mobiles [Rapport] : Rapport
de travail / Informatique ; I stitut de la f a opho ie pou l’i fo ati ue,. - Hanoï : IFI, 2009. - p. 48. -
http://www2.ifi.auf.org/rapports/tpe-promo14/tpe-tran_quoc_tuan.pdf.
 [TUR 06] M. Turuani The cl-atse protocol analyser [Revue] // In Frank Pfenning. - [s.l.] : RTA, 2006. - Vol.
volume 4098 of Lecture Notes in Computer. - pp. 277–286.
 [TWE 12] Twenga Hub Bluetooth : 8 offres parmi 5 boutiques [En ligne] // reseaux.twenga.fr. - 14 August
2012. - 14 August 2012. - http://reseaux.twenga.fr/hub-bluetooth.html.
 [VAL 07] Valentin Rudy Peripherique Bluetooth [Ouvrage]. - [s.l.] : 2 éme informatique Helho, 2007.
 [VAL 07b] Valentin Rudy Peripherique Bluetooth [En ligne] // http://www.hesit.be/. - 2007. - 24 11 2011. -
http://www.hesit.be/files/info/2/1211543976-Bluetooth_(Rapport).pdf.
 [VAN 07] VAN DEN BOSSCHE, Adrien P opositio d’u e ou elle thode d’a s d te i iste pou u
réseau personnel sans fil à fortes contraintes temporelles [Ouvrage]. - TOULOUSE : LABORATOIRE LATTIS EA
4155 Groupe SCSF Systèmes Communicants Sans Fil, 2007.
 [WST 12] W. Steven Conner Jan Kruys,Kyeongsoo (Joseph) Kim,Juan Carlos Zuniga, IEEE 802.11s Tutorial
Overview of the Amendment for Wireless Local Area Mesh Networking [En ligne] = 802.11s Interworking
Approach, // www.ieee802.org. - 13 November 2006. - 12 04 2012. -
http://www.ieee802.org/802_tutorials/06-November/802.11s_Tutorial_r5.pdf.
 [WIF 10] Wi-Fi Alliance Wi-Fi CERTIFIED Wi-Fi Di e t™: Co e t ith the possi ilities [Rappo t]. - [s.l.] : Wi-Fi
Alliance, 2010. www.netgear.fr [En ligne] // www.netgear.fr. -
http://www.netgear.fr/images/WN3000RP_fr65-17219.pdf.
 [YBO 05] Y. Boichut P.-C. Héam, O. Kouchnarenko Automatic verification of security protocols using
approximations [Rapport] = Report RR 5727,. - [s.l.] : INRIA,, 2005.
 [YAN 08] Yann GLOUCHE Thomas GENET,Erwan HOUSSAY, a Security Protocol ANimator for AVISPA
[Rapport] : User Manual / IRISA ; Université de Rennes 1. - Rennes : INRIA, 2008. - p. 18.
 [ZYG 03] Zygmunt J. Haas Marc R. Pearlman, Prince Samar The Intrazone Routing Protocol (IARP) for Ad Hoc
Networks [Rapport] / Cornell University. - 2003. - http://tools.ietf.org/html/draft-ietf-manet-zone-iarp-
02.txt. - RFC 2026.
 [ZYG 02] Zygmunt J. Haas Marc R. Pearlman, Prince Samar, The Interzone Routing Protocol (IERP) for Ad Hoc
Networks [Rapport] / Cornell University. - 2002. - http://tools.ietf.org/html/draft-ietf-manet-zone-ierp-02.txt.

Memoire de Master2 Approche Efficace Pou

Transféré par

Informations du document

Description :

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Description :

Droits d'auteur :

Memoire de Master2 Approche Efficace Pou

Titre original :

Transféré par

Description :

Droits d'auteur :

UNIVERSITÉ DE YAOUNDÉ I UNIVERSITY OF YAOUNDÉ I

MEMOIRE DE MASTER II INFORMATIQUE

NONO LOUENKAM Guy Gaspard

Dr. Thomas DJOTIO NDIÉ

ANNEE ACCADEMIQUE 2012-2013

 Je remercie tous les enseignants du Département d’informatique de la Faculté des sciences et de

Mémoire de Master II 1 NONO LOUENKAM Guy Gaspard

A mon père Mr. LOUENKAM Edouard

Mémoire de Master II 2 NONO LOUENKAM Guy Gaspard

Mémoire de Master II 3 NONO LOUENKAM Guy Gaspard

Mémoire de Master II 4 NONO LOUENKAM Guy Gaspard

Mémoire de Master II 5 NONO LOUENKAM Guy Gaspard

TABLE DES MATIERES

Mémoire de Master II 7 NONO LOUENKAM Guy Gaspard

II.4. L’INFRAROUGE ...................................................................................................... 23

Mémoire de Master II 8 NONO LOUENKAM Guy Gaspard

IV.4. Architecture logicielle ................................................................................................ 52

Mémoire de Master II 9 NONO LOUENKAM Guy Gaspard

Preuve de la relation (2) : ......................................................................................................... 70

LISTE DES FIGURES

Mémoire de Master II 10 NONO LOUENKAM Guy Gaspard

LISTE DES TABLEAUX

LISTE DES ALGORITHMES

Mémoire de Master II 11 NONO LOUENKAM Guy Gaspard

CHAPITRE I. INTRODUCTION GENERALE

Le domaine de la télécommunication a connu ces 20 dernières années des évolutions

Mémoire de Master II 12 NONO LOUENKAM Guy Gaspard

I.3. MOTIVATIONS ET OBJECTIFS

I.4. LES DOMAINES D’APPLICATIONS DE LA TELEPHONIE PAR

Les propriétés et l’évolution permanente de la technologie Bluetooth en termes de débit

Mémoire de Master II 13 NONO LOUENKAM Guy Gaspard

I.4.1. Application dans le domaine universitaire

I.4.2. Applications dans le domaine de la santé

I.4.3. Application dans le domaine administratif et en entreprise

Mémoire de Master II 14 NONO LOUENKAM Guy Gaspard

I.4.4. Application dans le domaine de la sécurité de proximité

I.4.5. Application dans le domaine de la publicité

I.6. STRUCTURE DU MEMOIRE

Mémoire de Master II 15 NONO LOUENKAM Guy Gaspard

Mémoire de Master II 16 NONO LOUENKAM Guy Gaspard

CHAPITRE II. ETAT DE L’ART

Mémoire de Master II 17 NONO LOUENKAM Guy Gaspard

II.1.2. Les services offerts par le GSM

II.1.3. Les limites du GSM

II.2. LE WI-FI: WIRELESS FIDELITY

II.2.1. Description du Wi-Fi

II.2.1.1. Les différentes normes du Wi-Fi

Mémoire de Master II 18 NONO LOUENKAM Guy Gaspard

Mémoire de Master II 19 NONO LOUENKAM Guy Gaspard

II.2.1.2. Les modes de fonctionnement du Wi-Fi

Figure 1 : Le mode infrastructure wifi

Mémoire de Master II 20 NONO LOUENKAM Guy Gaspard

Figure 2 : Le mode de fonctionnement Ad Hoc du Wi-Fi

 Le mode répéteur (range-extender) Un point d'accès en mode

répéteur permet de répéter un signal Wi-Fi plus loin (par exemple

II.2.1.3. Les équipements Wi-Fi

Mémoire de Master II 21 NONO LOUENKAM Guy Gaspard

Figure 4 : Exemples de points d’accès Wi-Fi

II.2.2. Application du Wi-Fi liée à la téléphonie : La VoIP

II.2.3. Les limites du Wi-Fi

II.3. LE WI-FI DIRECT

Mémoire de Master II 22 NONO LOUENKAM Guy Gaspard