These El Sayah

UNIVERSIT PARIS-EST
COLE DOCTORALE MATHMATIQUE ET STIC
THSE DE DOCTORAT
Spcialit : Electronique, Optronique et Systmes
Laboratoire ESYCOM Electronique, Systme de Communications et Microsystmes
Prsente et soutenue publiquement par
Jinane SAYAH
Le 18 dcembre 2009
Contribution la modlisation, la simulation et l'valuation dapplications

nomades intelligence rpartie Application lassistance aux voyageurs
aveugles dans les transports publics et les ples dchanges
Directeur de thse : Genevive Baudoin

Co-encadrants : Olivier Venard et Bachar El Hassan
Jury
Rapporteurs : Jaime Lopez Krahe, Professeur luniversit Paris 8

Mounir Mokhtari HDR, Matre de confrences Tlcom SudParis, HDR
Examinateurs : Genevive Baudoin, Professeur ESIEE Paris, HDR

Bachar El Hassan, Matre de confrences Universit libanaise
Venard Olivier, Matre de confrences ESIEE Paris
Martine Villegas, Professeur ESIEE Paris, HDR
Ahmed Seffah, Professeur EHL Lausanne, HDR
Remerciements
Je voudrais remercier tous ceux qui ont collabor la russite de ce travail.
Ma profonde reconnaissance ma directrice de thse, Genevive Baudoin, pour sa patience,

son appui et son soutien durant ces quatre annes.
Mes remerciements sincres mon encadrant Olivier Venard et mon co-encadrant Bachar El
Hassan pour leurs ides constructives et leurs commentaires pertinents.
Mes sentiments dvous mes deux rapporteurs, Jaime Lopez Krahe et Mounir Mokhtari pour
avoir accept de juger mon travail et Martine Villegas et Ahmed Seffah pour lhonneur quils
mavaient donn dtre examinateurs de ce mmoire.
Un grand merci au personnel de luniversit Paris-Est et de lESIEE pour leur acceuil

chaleureux et les moments agrables que jai passs avec eux malgr mes sjours un peu courts
mais qui vont srement me manquer.
Mes remerciements profonds et chaleureux ma famille et mon mari pour leurs

encouragements et leur aide inestimables.
Finalement un merci du fond du cur mon petit ange qui a chang mon monde et a t une
source despoir et de motivation prcieuse qui ma permis de mener cette thse jusquau bout.
Sincrement,
Jinane.
RSUM
Les dveloppements rcents dans le domaine des systmes de communication mobiles

(GSM/GPRS, UMTS, WIFI, WIMAX, ZigBee, Bluetooth, ULB), daide la localisation (GPS,
WPS, DRM), des nouveaux dispositifs mobiles intelligents comme les PDA et les tlphones
intelligents, de laccs aux donnes rendent possible le dveloppement de nouvelles applications
et services facilitant la vie quotidienne par un accs simple et gnralis des informations
temps rel. En particulier, de nouveaux services sont mis en uvre, permettant damliorer
lintgration des personnes handicapes notamment les personnes aveugles. Le sixime
programme cadre de recherche de lunion europenne a introduit ce propos la notion
dAmbient Intelligence.
De nombreuses technologies existent mais il faut pouvoir les intgrer dune manire
fiable et efficace en plaant lutilisateur final au centre des proccupations. Un point important
est le fonctionnement sans discontinuit perceptible par lutilisateur dans diffrents
environnements comme la maison, les transports publics, les espaces publics. Les applications et
services dvelopps doivent tre contrlables simplement par lutilisateur, ceci est dautant plus
vrai si lutilisateur est handicap.
Dans ce contexte, la thse a contribu au dveloppement dun systme dinformation et

de guidage destin aux personnes aveugles dans les transports publics. Les travaux sappuient
sur les acquis des projets RAMPE et INFOMOVILLE mens au sein dun partenariat entre
lESIEE, luniversit Paris 8, le cabinet Ergonomos et la socit LUMIPLAN. Le systme
RAMPE est form d'une infrastructure rseau ventuellement htrogne et de dispositifs
intelligents ports par lutilisateur. Chaque composant du systme (stations de base ou bornes,
dispositifs mobiles, serveurs de base de donnes) constitue un nud producteur et
consommateur dinformations et de services. Ce systme a pour vocation de faciliter les
dplacements dans les ples dchanges (bus, tramways, mtros ) qui sont des
environnements particulirement complexes pour un usager non familier qui doit dcouvrir les
possibilits lies son parcours. Cette situation est aggrave pour un voyageur aveugle.
INFOMOVILLE sinscrit dans le prolongement de RAMPE et a pour objectif de fournir des
informations temps-rel, daider lorientation et la scurit des voyageurs handicap
sensoriel (visuel ou auditif) dans les transports publics.
La thse a port sur deux aspects critiques de ce type de systmes : la fiabilit de la

transmission de donnes et la capacit localiser et guider lutilisateur de manire robuste.
Elle a dautre part dvelopp un environnement de simulation utilisant le logiciel OMNeT++
pour le prototypage et lanalyse du fonctionnement de lapplication nomade ainsi que ltude des
aspects rseaux de communication mobile.
Des limitations existent dans la version actuelle du systme RAMPE/INFOMOVILLE

notamment en ce qui concerne les protocoles de communication entre les bornes (quipant les
stations de bus) et les PDA (dispositif port par laveugle). Le prsent travail a conduit
proposer un protocole plus performant et plus adquat au type de trafic quon rencontre dans
lapplication RAMPE/INFOMOVILLE.
La technologie de communication WiFi adopte dans RAMPE/INFOMOVILLE peut

aussi servir des services supplmentaires notamment des services de localisation et de guidage.
i
Cette technologie, bien quelle soit disponible et largement implmente, est toutefois sujette
aux erreurs et affecte par divers facteurs. Elle peut donc manquer de la fiabilit requise pour
des systmes comme RAMPE/INFOMOVILLE. Pour pallier cette situation, on propose un
protocole, inspir dun protocole existant qui ajoute, dune part, une certaine fiabilit et sret
la communication, et dautre part, permet de fabriquer un indicateur de qualit de la transmission
rseau. Cet indicateur peut tre traduit en un message comprhensible par les utilisateurs du
systme pour leur donner un degr de confiance en lapplication et en leurs dispositifs. Cette
qualit de liaison peut tre value et estime selon plusieurs critres ; on a choisi un critre, le
taux derreurs paquet (PER), bien adapt lapplication et la technologie utilises. Pour
montrer lefficacit du protocole propos et le comparer aux protocoles actuels utiliss dans
RAMPE/INFOMOVILLE, on le simule sur deux types de canaux : un canal rel pouvant tre
perturb par plusieurs facteurs et interfrences, et un canal modlis par un modle de Gilbert-
Elliot en utilisant dans les deux cas le simulateur OMNeT++. Afin de minimiser le temps de
simulation, le modle de canal introduit simule les erreurs au niveau paquet. On dduit de
lidentification des paramtres du modle de canal, lindicateur de qualit de transmission
permettant dlaborer un niveau de confiance pour lutilisateur.
Le systme RAMPE/INFOMOVILLE dans sa version actuelle ne propose pas de rel

service de guidage ou de localisation pour les voyageurs aveugles lexception dun guidage
sonore lapproche des bornes. Pourtant linfrastructure et la technologie WiFi utilise pour la
communication peut tre utilise en localisation et guidage afin daider lutilisateur atteindre sa
destination qui peut tre un arrt de bus au sein dun ple dchanges ; Cette technologie peut
tre utilise aussi bien dans les zones extrieures que dans les zones intrieures. Les systmes de
localisation existants utilisant la technologie WiFi avec une mthode dempreinte radio
permettent dobtenir une prcision suffisante pour ce type dapplication mais prsentent comme
inconvnient important le temps ncessaire pour calibrer un site avec la prcision voulue pour
guider des personnes aveugles ou malvoyantes. Dans cette thse, on propose une approche de la
localisation et du guidage permettant de rpondre aux besoins des utilisateurs tout en minimisant
les contraintes pour les exploitants des rseaux de transport. Cette approche repose sur la notion
de chemins privilgis correspondant aux parcours possibles dans un ple dchanges. Ces
chemins privilgis sont calibrs avec une prcision suprieure celle des autres zones. Cette
approche permet de rduire de manire importante le temps de calibration dun site tout en
conservant les performances requises. Dautres facteurs doivent aussi tre considrs comme
linfluence du dplacement ou de la panne ventuelle des points daccs WiFi utiliss pour la
localisation. Ces diffrents aspects et les solutions proposes ont t tests et valids par des
exprimentations sur site.
Mots cls
Applications nomades, systmes dinformation, aveugles et malvoyants, transports en commun,

localisation, guidage, WiFi, WiFi Positioning System (WPS), protocoles rseau, PDA.
ii
ABSTRACT
The recent developments of mobile communication systems (GSM/GPRS, UMTS,

WIFI, WIMAX, ZigBee, Bluetooth, UWB), location systems (GPS, WPS, DRM), new
intelligent mobile devices (Personal Digital Assistant (PDA), smartphones), structuring and data
access, have made possible the development of new services and applications making daily life
easier by a simple and generalized access to real time information. In particular, new services
are elaborated to improve the integration of handicapped people precisely the visually impaired
or blind people. The sixth research program of the European Union has introduced in this
context the notion of Ambient Intelligence.
Many technologies exist but it is necessary to integrate them in a reliable and effective
way while giving intensive care to the end user. An important point is to guarantee the end user
a continuous service in various environments like the house, public transports and public spaces.
The developed applications and services must be simply controllable by the user especially if the
user is handicapped.
In this context, this thesis contributed in the development of an information and guidance
system for the blind people in the poles of transport interactions; it will be based on the assets of
the RAMPE/INFOMOVILLE project carried out in partnership between ESIEE, Paris 8
university, the Ergonomos cabinet and LUMIPLAN company. The RAMPE system (in french-
Rfrentiel d'assistance aux personnes Aveugles pour leur Mobilit dans les transports publics et
les Ples d'Echanges), is composed of an eventually heterogeneous network infrastructure and
smart devices carried by the blind user. Each component of the system (base stations, mobile
devices, databases) is a producer and consumer of information and services. The objective of
this system is to increase the mobility and autonomy in the poles of transport interactions (bus,
trams, trains) which are particularly complex environments for a nonfamiliar user who has to
discover the paths and possibilities related to his transport; this is worsen for a blind traveler.
INFOMOVILLE is on the extension of RAMPE; its objective is to provide real time
information, orientation and security assistance for handicapped travellers (blinds and deafs) in
public transports and cities.
The thesis has focused on two critical aspects of this type of systems: the reliability of
data transmission and the capacity to locate and guide the user in a robust way. In addition, a
simulation environment using the OMNeT++ was developed for the prototyping and the analysis
of the applications operation.
Limitations exist in the current version of RAMPE/INFOMOVILLE particularly in the

communication protocols used between the terminals (installed in bus station) and the PDA
(device carried by the blind). This work contributed in proposing a more powerful and adequate
protocol to the type of traffic found in RAMPE/INFOMOVILLE.
The WiFi technology adopted in RAMPE/INFOMOVILLE can also be used in

additional services in particular in localization and guidance. Although this technology is
available and largely implemented, it is prone to many errors and affected by various factors. It
can thus miss the reliability required by systems like RAMPE/INFOMOVILLE.
iii
To remedy this situation, a new protocol was proposed which adds a certain reliability and
safety to the communication; on the other hand, it allows elaborating a quality indicator of the
network. This indicator can be translated into a comprehensible message which can offer the
users a confidence degree in their application and device. This quality of connection can be
evaluated and estimated according to several criterias; we have chosen the Packet Error Rate
(PER) criteria, well adapted to the application and technology used. To show the effectiveness of
the suggested protocol and to compare it withn the current protocols used in
RAMPE/INFOMOVILLE, we simulated it over two types of channels: a real channel being able
to be disturbed by several factors and interferences, and a modeled Gilbert-Elliot channel, using
in both cases the OMNeT++ simulator. In order to minimize the simulation time, the introduced
channel model simulates the errors on the packet level. We deduce from the identification of the
modeled channel parameters, the transmission quality indicator allowing elaborating a
confidence degree for the user.
The RAMPE/INFOMOVILLE system, in its current version, does not propose a real
localization and guidance service for the blind travellers except an auditive sound emitted by the
base station of the bus stop allowing the blind to be guided towards it. However WiFi can be
also adopted in localization and guidance services, allowing helping the blind to reach his/her
destination which can be a bus station or a pole of transport interactions. WiFi could be used in
both indoor and outdoor areas. The existing WiFi localization systems use the radio
fingerprinting technique allowing a sufficient precision for this type of application but present a
major drawback which is the time needed to calibrate a site for a required precision. We
proposed in this thesis a new localization and guidance approach allowing meeting the users
needs while minimizing the constraints related to the system maintenance and implementation.
This approach is based on the concept of privileged paths which correspond to the possible
routes in a pole of transport interactions. These paths are calibrated with a higher precision than
the remaining zones of the site which reduce the calibration time while preserving the necessary
performance. Other factors are to be considered as well like the displacement or the possible
breakdown of the access points which will influence the localization precision; these various
aspects and the suggested solutions were tested and validated by experiments done on site.
Keywords
Mobile applications, information system, blind and visually impaired, public transports,
localization, guidance, WiFi, WiFi Positioning System (WPS), network protocols, PDA.
iv
LISTE DES PUBLICATIONS RALISES AU COURS DE LA THSE
(1) J. Sayah, G. Baudoin, O.Venard, B. El Hassan. Simulation using OMNeT++ of the

RAMPE system - an Interactive Auditive Machine helping blinds in Public Transport.
Proc. of 3rd IEEE Region 8 International Conference on Computer as a Tool, EUROCON
2005, Volume 2, p. 1028 - 1031. Serbia & Montenegro, Belgrade. November 2005.
(2) J. Sayah, G. Baudoin, O.Venard, B. El Hassan. Architecture and Protocols of the RAMPE
system- An Interactive Auditive Machine Helping Blinds in Public Transport. Proc. of the
2nd IEEE International Conference on Information & Communication Technologies: from
Theory to Applications, ICTTA06, Volume 1, p. 843 - 848. Umayyad Palace, Damascus,
Syria. April 2006.
(3) J. Sayah, G. Baudoin, O.Venard, B. El Hassan. RAMPE/INFOMOVILLE Application

Protocol- Protocole Point Multipoint adapt au systme RAMPE/INFOMOVILLE-
Assistance aux Personnes Handicap Sensoriel pour leur Mobilit dans les Transports
Publics et en Ville. 5th International Conference on Sciences of Electronic, Technologies
of Information and Telecommunications, SETIT 2009. Hammamat, Tunisia. March 2009.
(4) J. Sayah, G. Baudoin, O.Venard, B. El Hassan. Localization and Guidance in

RAMPE/INFOMOVILLE- an Interactive System of Assistance for Blind Travelers. 2nd
International Conference on the Applications of Digital Information and Web
Technologies, ICADIWT 2009. August 4-6 2009, London Metropolitan University, UK.
v
TABLE DES MATIRES
Rsum.............................................................................................................. i
Abstract ............................................................................................................ iii
Liste des publications ralises au cours de la thse .......................................... v
Liste des abbrviations ..................................................................................... ix
Liste des tableaux ............................................................................................. xi
Liste des figures .............................................................................................. xii
Introduction ..................................................................................................... 1
Motivations et objet de la thse .............................................................................. 1
Principales contributions ........................................................................................ 2
Organisation du manuscrit ..................................................................................... 3
Chapitre 1 ......................................................................................................... 5
Les systmes RAMPE et INFOMOVILLE .............................................................. 5
1.1 Introduction ............................................................................................ 5
1.2 Systmes dassistance aux personnes dficientes de la vision ........................ 6
1.3 Prsentation et historique de RAMPE/INFOMOVILLE .................................... 13
1.3.1 Constituants et Architecture .............................................................. 14
1.3.2 Principe et fonctionnement ............................................................... 15
1.4 Simulation de RAMPE/INFOMOVILLE dans lenvironnement OMNeT++ .......... 19
1.4.1 Introduction sur OMNeT++ ............................................................... 19
1.4.2 Simulation de RAMPE/INFOMOVILLE .................................................. 22
1.5 Limitations du systme RAMPE test Lyon............................................... 23
1.6 Proposition damlioration du guidage auditif par le carillon des bornes ......... 24
Chapitre 2 ........................................................................................................26
Technologies sans fil de communication et de localisation ...............................26
2.1 Motivations ........................................................................................... 26
2.2 Technologies de communication sans fil courte distance .............................. 26
2.2.1 Zigbee ........................................................................................... 27
2.2.1.1 Norme IEEE 802.15.4 ................................................................... 27
2.2.1.2 ZigBee et les couches IEEE ............................................................ 27
2.2.2 Bluetooth ....................................................................................... 29
2.2.2.1 Norme IEEE 802.15.1 ................................................................... 29
2.2.2.2 Bluetooth et les couches IEEE ........................................................ 30
2.2.3 Wi-Fi (Wireless Fidelity) ................................................................... 31
2.2.3.1 Norme IEEE 802.11 ...................................................................... 32
2.2.3.2 WiFi et les couches OSI- Couche Physique ....................................... 33
2.2.3.3 Les modes dopration de 802.11 ................................................... 34
2.2.3.4 La couche Liaison de Donnes........................................................ 38
2.2.3.5 Itinrance et rassociation ............................................................ 41
2.2.3.6 Dbit rel et dbit thorique .......................................................... 43
2.3 Golocalisation - Techniques et systmes .................................................. 45
2.3.1 Gnralits ..................................................................................... 45
2.3.2 Mthodes et Techniques de Golocalisation ......................................... 45
2.3.2.1 Mthodes gomtriques ................................................................ 46
2.3.2.2 Mthodes Statistiques ................................................................... 47
vi
2.3.2.3 Mthodes Hybrides ....................................................................... 48
2.3.3 Techniques de mesure ..................................................................... 48
2.3.4 Systmes de localisation .................................................................. 49
2.3.4.1 Localisation par Satellite ............................................................... 49
2.3.4.2 WiFi Positioning System (WPS) ...................................................... 51
2.3.4.3 Systmes de localisation par ondes radiofrquences ou infrarouges ..... 53
2.3.4.4 Systmes de localisation utilisant la diffusion des signaux de tlvision 54
2.3.4.5 Systmes de localisation utilisant les systmes de communications
cellulaires ................................................................................................ 54
2.4 Conclusion ............................................................................................ 55
Chapitre 3 ........................................................................................................57
RAMPE/INFOMOVILLE Application Protocol......................................................57
3.1 Introduction et objectifs .......................................................................... 57
3.2 Indicateur de qualit dun lien WiFi ........................................................... 58
3.3 Modlisation dun canal radio 802.11 ........................................................ 59
3.4 Protocoles utiliss dans RAMPE/INFOMOVILLE ............................................ 60
3.5 Transmission point--multipoint ............................................................... 61
3.6 Protocole RAP ........................................................................................ 62
3.6.1 Mcanisme de fonctionnement de RAP................................................ 62
3.6.2 RAP- protocole de la couche Session .................................................. 63
3.6.3 Format de la trame de Service RAP .................................................... 64
3.6.4 Trame de Bourrage.......................................................................... 65
3.6.5 Trame de Statistique ....................................................................... 65
3.6.6 Autres problmes et remdes............................................................ 66
3.7 Simulation et valuation de RAP............................................................... 66
3.7.1 Simulation sur un canal rel.............................................................. 66
3.7.1.1 Exprimentation .......................................................................... 67
3.7.1.2 Elments de lexprimentation ....................................................... 68
3.7.1.3 Simulation des protocoles RAP et UDP ............................................. 74
3.7.1.4 Tableau rcapitulatif comparatif (UDP vs. RAP sur un canal rel) ......... 78
3.7.1.5 Interprtations et observations ...................................................... 81
3.7.2 Identification des paramtres du canal WiFi ........................................ 83
3.7.3 Simulation sur un modle de canal de Gilbert-Elliot .............................. 86
3.7.3.1 Description de la simulation ........................................................... 86
3.7.3.2 Tableau comparatif (UDP vs. RAP sur un canal de Gilbert-Elliot) .......... 87
3.7.3.3 Histogrammes du canal de mauvaise qualit de Gilbert-Elliot.............. 88
3.7.4 Comparaison UDP - RAP ................................................................... 89
3.7.5 Analyse ......................................................................................... 89
Chapitre 4 ........................................................................................................90
Positionnement et guidage dans RAMPE/INFOMOVILLE ...................................90
4.1 Introduction .......................................................................................... 90
4.2 Principes dun systme de localisation radio et infrastructure ncessaire ....... 91
4.2.1 Calibrage ....................................................................................... 91
4.2.2 Positionnement ............................................................................... 92
4.2.2.1 Algorithmes de positionnement ...................................................... 93
4.2.3 Systme Ekahau ............................................................................. 97
4.3 Besoins utilisateurs et contraintes dexploitation ......................................... 98
4.3.1 Besoins utilisateurs.......................................................................... 98
4.3.2 Contraintes dexploitation ............................................................... 102
4.4 Proposition dune mthodologie de calibrage avec chemins privilgis ........ 104
4.5 Exprimentation .................................................................................. 105
4.5.1 Description du site et de linfrastructure de lexprimentation .............. 105
4.5.2 Elments de lexprimentation ........................................................ 107
4.5.3 Scnario de base (scnario 1)- Calibrage uniforme du site................... 108
vii
4.5.3.1 Mthodologie de calibration ......................................................... 108
4.5.3.2 Positionnement et rsultats de prcision ........................................ 109
4.5.3.3 Impact de la mobilit sur la prcision ............................................ 110
4.5.4 Scnario propos (scnario 2) - RAMPE/INFOMOVILLE RWPS ............... 112
4.5.4.1 Mthodologie de calibration ......................................................... 112
4.5.4.2 Rsultats de prcision ................................................................. 113
4.5.4.3 Rflexions ................................................................................. 114
4.5.4.4 Impact de la mobilit sur la prcision ............................................ 114
4.5.5 Scnarios de modifications et de perturbations .................................. 115
4.5.5.1 Scnario 3 - Elimination de quelques APs avant le calibrage ............. 116
4.5.5.2 Scnario 4 Suppression dAPs pendant le positionnement .............. 117
4.5.5.3 Scnario 5 - Dplacement des APs................................................ 119
4.6 Guidage dans les diffrents scnarios ..................................................... 123
4.6.1 Guidage dans le scnario de calibrage uniforme (scnario 1) ............... 123
4.6.2 Guidage dans le scnario de RWPS (scnario 2) ................................. 126
4.6.3 Guidage dans le scnario dlimination dAPs avant le calibrage ........... 128
4.6.4 Guidage dans le scnario de suppression dAPs pendant le positionnement
130
4.6.5 Guidage dans le scnario de dplacement des APs ............................. 131
4.6.6 RSSI durant le guidage .................................................................. 134
4.6.7 Analyse ....................................................................................... 137
4.7 Intgration dans RAMPE/INFOMOVILLE ................................................... 138
Conclusions et perspectives ........................................................................... 141

Principales contributions .................................................................................... 141
Perspectives et travaux futurs............................................................................. 142
Bibliographie ................................................................................................. 146
Annexe A ....................................................................................................... 161

Ekahau Real time Location System (RTLS) ..................................................... 161
Annexe B ....................................................................................................... 167

Installation dOMNeT++................................................................................. 167
Annexe C ....................................................................................................... 169

Codes de simulation ....................................................................................... 169
viii
LISTE DES ABBRVIATIONS
ACK Acknowledgment (Acquittement)

AP Access Point
AoA Angle of Arrival
BER Bit Error Rate
BSA Basic Service Area
BSS Basic Service Set
BSSID Basic Service Set Identification
CAP Contention Access Period
CCK Complementary Code Keying
CFP Contention Free Period
CP Contention Period
CRC Cyclic Redundancy Check
CSMA/CA Carrier Sense Multiple Access with Collision Avoidance
CSMA/CD Carrier Sense Multiple Access with Collision Detection
CTS Clear To Send
CW Contention Window
DCF Distributed Coordination Function
DHCP Dynamic Host Configuration Protocol
DIFS Distributed Coordination Function Inter-Frame Space
DS Distribution System
DSAP Destination Service Access Point
DSSS Direct Sequence Spread Spectrum
EIFS Extended Inter-Frame Space
ESA Extended Service Area
ESS Extended Service Set
FCS Frame Check Sequence
FH Frequency Hopping
FHSS Frequency-Hopping Spread Spectrum
GNED Graphical NEtwork Descriptor
GPS Global Positioning System
HTTP Hypertext Transfer Protocol
IBSS Independent Basic Service Set
IEEE Institute of Electrical and Electronics Engineers
IFS Interframe Space
INFOMOVILLE Environnement temps-rel pour lINFOrmation, lorientation et la
scurit des voyageurs handicap sensoriel (visuel ou auditive)
au cours de leurs dplacements dans les transports collectifs, les
ples dchanges et de faon plus gnrale pour la MObilit en
VILLE
IP Internet Protocol
IR Infra rouge (Infrared)
ix
ISM Industrial, Scientific, and Medical
LAN Local Area Network
LLC Logical Link Control
MAC Medium Access Control
MMI Man Machine Interface
MTU Maximum Transmission Unit
NED NEtwork Descriptor
OMNeT++ Objective Modular Network Testbed in C++
OSI Open Systems Interconnection
PAM Personne Aveugle ou Malvoyante
PCF Point Coordination Function
PDA Personal Digital Assistant
PDR Packet-Delivery Ratio
PER Packet Error Rate
PIFS Point Coordination Function Inter- Frame Space
PP Preferred Path
PR Point de Rfrence
QoS Quality of Service
RAMPE Rfrentiel dAssistance aux personnes aveugles pour leur Mobilit
dans les transports publics et les Ples dEchange
RAP RAMPE/INFOMOVILLE Application Protocol
R&D Recherche et Dveloppement
RF Radio-Frquence (RadioFrequency)
RSB Rapport Signal sur Bruit
RSSI Received Signal Strength Indicator
SIFS Short Inter-Frame Space
SINR Signal-to-Interference-plus-Noise Ratio
SNR Signal to Noise Ratio
STA Station Mobile
TCP Transmission Control Protocol
TDoA Time Difference of Arrival
ToA Time of Arrival
UDP User Datagram Protocol
UM Utilisateur Mobile
UNII Universal Networking Information Infrastructure band
WECA Wireless Ethernet Compatibility Alliance
WEP Wired Equivalent Privacy
WLAN Wireless Local Area Network
WiFi Wireless Fidelity
WPA Wi-Fi Protected Access
WPS WiFi Positioning System
XML Extensible Markup Language
x
LISTE DES TABLEAUX
Table 1- Technologies de communication sans fil ........................................................ 27

Table 2- Les trios classes de modules radio Bluetooth ................................................. 31
Table 3- Les diffrentes normes WiFi ........................................................................ 33
Table 4- Dcoupage de la bande dans 802.11b/g........................................................ 33
Table 5- Dcoupage de la bande dans 802.11a (zone intrieure) .................................. 34
Table 6- Dcoupage de la bande dans 802.11a (zone extrieure) .................................. 34
Table 7 Les trames RAMPE/INFOMOVILLE ................................................................ 61
Table 8- Les catgories des trames RAP .................................................................... 63
Table 9- Spcifications du matriel de la manipulation ................................................. 68
Table 10- Comparaison UDP et RAP (canal rel) ......................................................... 81
Table 11- UDP vs. RAP (canal Gilbert-Elliot optimis et de mauvaise qualit) .................. 87
Table 12- Canal de mauvaise, moyenne et bonne qualit ............................................. 88
Table 13- RAP vs. UDP (canal rel et canal simul) ..................................................... 89
Table 14- Composants du systme Ekahau ................................................................ 97
Table 15- Longueur des diffrents PPs..................................................................... 108
Table 16- Rsultats de prcision moyenne pour le scnario de base ............................ 110
Table 17- Impact de la mobilit sur la prcision dans le scnario 1 .............................. 112
Table 18- Performances en prcision de RWPS ......................................................... 114
Table 19- Impact de la mobilit sur la prcision dans le scnario 2 .............................. 115
Table 20- Elimination dAPs pendant le calibrage ...................................................... 117
Table 21- APs en panne pendant le positionnement .................................................. 118
Table 22- Dplacement d'un AP pendant le positionnement ....................................... 120
Table 23- Dplacement de 2 APs pendant le positionnement ..................................... 121
Table 24- Dplacement de 3 APs de 10 mtres......................................................... 122
Table 25- Temps de guidage dans le scnario de calibrage uniforme ........................... 126
Table 26- Temps de guidage dans RWPS ................................................................. 128
Table 27- Temps de guidage dans le scnario dlimination dAPs avant le calibrage ...... 130
Table 28- Temps de guidage dans le scnario de suppression d'APs pendant le
positionnement .................................................................................................... 131
Table 29- Temps de guidage dans le scnario de dplacement dun AP (de 20 mtres) .. 133
Table 30- Temps de guidage dans le scnario de dplacement de 2 APs ....................... 134
xi
LISTE DES FIGURES
Figure 1- Motivations et contributions de la thse ......................................................... 4

Figure 2- Architecture gnrale du systme RAMPE/INFOMOVILLE ................................ 14
Figure 3- Structure de l'application sur PDA ............................................................... 15
Figure 4- Les boutons et les deux modes de fonctionnement du PDA ............................. 16
Figure 5- Association du PDA au point d'accs ............................................................ 17
Figure 6- Sonnerie de la borne et tlchargement de la base de donnes ....................... 17
Figure 7- Les trois niveaux de navigation dans la base de donnes ................................ 18
Figure 8- Les quatre phases d'utilisation de RAMPE/INFOMOVILLE [2] ........................... 18
Figure 9- Tkenv avec OMNeT++............................................................................... 21
Figure 10- Les composants de RAMPE/INFOMOVILLE dans un fichier NED dOMNeT++ ..... 22
Figure 11- Rseau Scatternet Bluetooth .................................................................... 30
Figure 12- Les deux couches de 802.11 .................................................................... 33
Figure 13- Mode Infrastructure de 802.11 ................................................................. 35
Figure 14 Oprations effectues dans 802.11 en mode infrastructure........................... 37
Figure 15- Mode Ad-Hoc de 802.11 .......................................................................... 38
Figure 16 Fonctionnement du CSMA/CA ................................................................... 39
Figure 17 Protocole Request To Send/Clear To Send (RTS/CTS) .................................. 40
Figure 18 Itinrance entre les points daccs ............................................................ 41
Figure 19 Itinrance et rassociation ....................................................................... 42
Figure 20 Handover avec un seul AP ....................................................................... 42
Figure 21 Chevauchement des rayons daction des APs .............................................. 43
Figure 22- Principe de localisation GPS ...................................................................... 50
Figure 23- Les deux tats du modle de canal de Gilbert-Elliot ..................................... 59
Figure 24- Format du trafic dans le protocol RAP propos ............................................ 63
Figure 25- Format de la trame de Service RAP ........................................................... 64
Figure 26- Format de la trame de Statistique RAP ....................................................... 66
Figure 27- Modle NED Client- Serveur de simulation sur un canal rel .......................... 67
Figure 28- Infrastructure de lexprimentation ........................................................... 69
Figure 29- Histogrammes des bons et mauvais tats de la simulation dUDP et de RAP sur
un canal rel ......................................................................................................... 85
Figure 30- Identification des paramtres du canal WiFi ................................................ 86
un canal de Gilbert-Elliot ......................................................................................... 88
Figure 32- Phase de calibrage de la mthode d'empreinte digitale ................................. 92
Figure 33- Phase de localisation de la mthode d'empreinte radio ................................. 93
Figure 34- Vue Google satellite du site de lexprimentation ....................................... 105
Figure 35- Photos du site d'exprimentation ............................................................ 106
Figure 36- Infrastructure de la manipulation ............................................................ 107
Figure 37- Banc de test de la manipulation de localisation .......................................... 108
Figure 38- Scnario de base: calibrage uniforme ...................................................... 109
Figure 39- Trajet effectu pour l'tude de l'impact de la mobilit sur la prcision de
localisation.......................................................................................................... 111
Figure 40- RWPS : calibrage fin sur les PPs .............................................................. 113
Figure 41- Trajets effectus pour l'tude de l'impact de la mobilit sur la prcision de
localisation.......................................................................................................... 115
Figure 42- Calibrage avec moins dAPs .................................................................... 116
Figure 43- APs en panne pendant le positionnement ................................................. 118
Figure 44- Dplacement dun seul AP pendant la phase de positionnement ................... 119
Figure 45- Dplacement de 2 APs pendant la phase de positionnement ........................ 121
Figure 46- Dplacement de 3 APs pendant la phase de positionnement ........................ 122
Figure 47- Guidage dans le scnario de calibrage uniforme ........................................ 125
xii
Figure 48- Guidage utilisant RWPS ......................................................................... 127
Figure 49- Guidage dans le scnario de suppression dAPs avant le calibrage ................ 129
Figure 50- Guidage dans le scnario de suppression dAPs pendant le positionnement .... 131
Figure 51- Guidage dans le scnario de dplacement d'un AP (de 20 mtres) ............... 132
Figure 52- Guidage dans le scnario de dplacement de 2 APs (de 20 mtres) .............. 134
Figure 53- UM1 et UM2 durant le guidage du scnario de base (scnario n1)............... 135
Figure 54- UM1 et UM2 durant le guidage du scnario 2 (RWPS) ................................. 135
Figure 55- RSSI des 8 APs pour les diffrents UM ..................................................... 137
Figure 56- Intgration de RWPS ............................................................................. 139
Figure 57- Insrer lchelle exacte de la carte du site ................................................ 161
Figure 58- Puissance des signaux des APs visualiss sur Ekahau Manager .................... 162
Figure 59- Les rails de cheminement ...................................................................... 163
Figure 60- Plan du site de lexprimentation ............................................................ 163
Figure 61- Enregistrement des PR .......................................................................... 164
Figure 62- Carte du site calibre ............................................................................ 165
Figure 63- Positionnement des clients agents ........................................................... 165
Figure 64- Spcifications du client localiser ........................................................... 166
xiii
Introduction
Introduction
Motivations et objet de la thse
Lintgration des personnes handicapes constituent lun des enjeux de nos socits ; en
France, la loi du 11 fvrier 2005 pour l'galit des droits et des chances affirme le principe
d'accessibilit pour tous, en particulier dans les transports [92, 94]. Dans le cadre de cette thse,
on sest intress aux personnes aveugles ou malvoyantes (PAM). La complexit et la grande
diversit des infrastructures urbaines rendent difficile lautonomie de dplacement des PAM.
Les transports en particulier se caractrisent pour les voyageurs handicap visuel par un fort
niveau dincertitude.
De nombreuses technologies sont disponibles mais il faut pouvoir les intgrer dune
manire fiable et efficace en plaant lutilisateur final au centre des proccupations. Un point
important est le fonctionnement sans discontinuit perceptible par lutilisateur dans diffrents
environnements comme la maison, les transports en commun, les espaces publics. Les
applications et services dvelopps doivent tre contrlables simplement par lutilisateur, ceci
est dautant plus vrai si lutilisateur est handicap.
Dans ce contexte, la thse a contribu au dveloppement dun systme dinformation et

de guidage destin aux personnes aveugles dans les transports publics. Les travaux se sont
appuys sur les acquis des projets RAMPE et INFOMOVILLE [1, 2, 61, 62, 113] mens au sein
dun partenariat entre lESIEE, luniversit Paris 8, le cabinet Ergonomos et la socit
LUMIPLAN. Le systme RAMPE est form d'une infrastructure rseau ventuellement
htrogne et de dispositifs intelligents ports par lutilisateur. Chaque composant du systme
(stations de base ou bornes, dispositifs mobiles, serveurs de base de donnes) constitue un nud
producteur et consommateur dinformations et de services. Ce systme a pour vocation de
faciliter les dplacements dans les ples dchanges (bus, tramways, mtros ) qui sont des
environnements particulirement complexes pour un usager non familier qui doit dcouvrir les
possibilits lies son parcours. Cette situation est aggrave pour un voyageur aveugle.
INFOMOVILLE sinscrit dans le prolongement de RAMPE et a pour objectif de fournir des
informations temps-rel, daider lorientation et la scurit des voyageurs handicap
sensoriel (visuel ou auditif) dans les transports publics. .
La thse a port sur deux aspects critiques de ce type de systmes : la fiabilit de la

transmission de donnes et la capacit localiser et guider lutilisateur de manire robuste.
Elle a dautre part dvelopp un environnement de simulation utilisant le logiciel OMNeT++
[21] pour le prototypage et lanalyse du fonctionnement de lapplication nomade ainsi que
ltude des aspects rseaux de communication mobile.
Concevoir un systme dassistance aux dplacements des PAM dans les transports
collectifs ncessite une analyse approfondie des besoins et des stratgies de dplacement de ces
personnes. Lanalyse ergonomique intervient diffrents niveaux dans le projet : analyse de
lactivit relle des personnes, diagnostic pour les besoins futurs, conception des interfaces
homme-machine (IHM) des nouveaux systmes daide, test du ou des systmes dans un
environnement naturel. Le projet sappuie pour cela sur les comptences des quipes
dergonomes partenaires du projet.
Applications nomades intelligence rpartie 1

Universit Paris-Est
Introduction
Principales contributions
notamment en ce qui concerne les protocoles de communication entre les bornes (quipant les
stations de bus) et les PDA (dispositif port par laveugle). Le prsent travail a propos des
protocoles plus performants et mieux adapts au type de trafic quon rencontre dans
lapplication RAMPE/INFOMOVILLE. La technologie de communication WiFi adopte dans
RAMPE/INFOMOVILLE, bien quelle soit disponible et largement implmente, est toutefois
sujette aux erreurs et affecte par divers facteurs [41]. Elle peut donc manquer de la fiabilit
requise pour des systmes comme RAMPE/INFOMOVILLE. Pour pallier cette situation, une
contribution de la thse a t de proposer un protocole, inspir dun protocole existant [20], qui
ajoute, dune part, une certaine fiabilit et sret la communication, et dautre part, permet de
fabriquer un indicateur de qualit de la transmission rseau. Cet indicateur peut tre traduit en un
message comprhensible par les utilisateurs du systme pour leur donner un degr de confiance
en lapplication et en leurs dispositifs. Cette qualit de liaison peut tre value et estime selon
plusieurs critres [44] ; on a choisi un critre, le taux derreurs paquet (PER), bien adapt
lapplication et la technologie utilises. Le protocole de communication propos peut tre
utilis en mode broadcast et sert fiabiliser le protocole UDP en introduisant une certaine
redondance ; il est appliqu la la diffusion des messages urgents, depuis la borne installe dans
la station de bus vers les dispositifs des utilisateurs. Pour montrer lefficacit du protocole
propos et le comparer aux protocoles actuels utiliss dans RAMPE/INFOMOVILLE, on le
simule sur deux types de canaux: un canal rel pouvant tre perturb par plusieurs facteurs et
interfrences, et un canal modlis par un modle de Gilbert-Elliot en utilisant dans les deux cas
le simulateur OMNeT++. Afin de minimiser le temps de simulation, le modle de canal
introduit simule les erreurs au niveau paquet [23]. On dduit de lidentification des paramtres
du modle de canal, lindicateur de qualit de transmission permettant dlaborer un niveau de
confiance pour lutilisateur.
Le systme RAMPE/INFOMOVILLE dans sa version actuelle ne propose pas de rel

service de guidage ou de localisation pour les voyageurs aveugles [1, 2, 61, 62] lexception
dun guidage sonore lapproche des bornes. Plusieurs systmes et techniques de localisation
existent actuellement, mais on a choisi dutiliser une approche exploitant linfrastructure radio
utilise pour les communications WIFI ce qui permet son intgration dans lapplication sans
ncessiter dquipements supplmentaires. De plus, cette technologie peut tre utilise aussi bien
dans les zones extrieures que dans les zones intrieures et offre ainsi une continuit de service
difficile avec dautres systmes. La golocalisation par ondes WIFI peut utiliser diffrents
principes, le plus simple sappuyant sur une triangulation entre des bornes WIFI. Lun des plus
performants en termes de prcision utilise la mthode de cartographie ou dempreinte radio.
Cette mthode ncessite une phase de calibrage du site de faon gnrer une empreinte ou
carte radio du site o on veut la mettre en place. Cette calibration consiste en une collecte et une
sauvegarde de mesures qui sont ensuite utilises pour entraner un modle statistique
empreinte radio du site. Cette empreinte radio est ensuite exploite par le systme de calcul
de position. La phase de calibration est dautant plus longue que la prcision finale souhaite est
grande. Ceci constitue une contrainte pour les oprateurs de transport souhaitant utiliser cette
approche. Une des contributions de la thse a t de proposer une mthodologie de calibration
adapte des applications du type de RAMPE/INFOMOVILLE avec un objectif de rpondre
aux besoins des utilisateurs en terme de prcision tout en minimisant les contraintes pour les
exploitants des rseaux de transport. La mthodologie propose effectue une calibration plus
fine dans certaines zones que dans dautres, pour renforcer la prcision de localisation dans

Universit Paris-Est
Introduction
celles-ci. Les zones dintrt dans la mthode propose sont les chemins qui peuvent tre
emprunts par la PAM pour aboutir sa destination (cheminement entre deux arrts de bus sur
une place par exemple). Lide est dorienter les personnes vers ces chemins privilgis sur
laquelle le cheminement est plus facile et o la prcision de localisation est meilleure. Cette
approche permet de rduire de manire importante le temps de calibration dun site tout en
conservant les performances de prcision requises. Dautres facteurs doivent aussi tre
considrs comme linfluence du dplacement ou de la panne ventuelle des points daccs
WiFi utiliss pour la localisation Ces diffrents aspects et les solutions proposes ont t tests
et valids par des exprimentations sur site.
Organisation du manuscrit
Le document comprend 4 chapitres principaux, une introduction, une conclusion et trois
annexes.
Lintroduction rsume les motivations de la thse, ses principales contributions, et

prsente lorganisation du manuscrit.
Le chapitre 1 dcrit le systme RAMPE/INFOMOVILLE : son historique, ses

composants, son fonctionnement et dresse un tat de lart succinct des systmes daide aux
dplacements des PAM en cours de dveloppement ou dj implments. Il prsente par ailleurs
la simulation du fonctionnement de RAMPE/INFOMOVILLE dans lenvironnement du
simulateur OMNeT++ [21]. Le chapitre se termine par quelques considrations de nature
ergonomique.
Dans le chapitre 2, on effectue un tat de lart comparatif des technologies de

communication sans fil courte distance ainsi que des systmes de gopositionnement et des
techniques de localisation. Le choix de WiFi pour lapplication RAMPE/INFOMOVILLE est
justifi pour une utilisation la fois pour la communication et la localisation.
Le chapitre 3 est ddi au travail effectu sur les protocoles de communication. Il dtaille
les protocoles utiliss dans lapplication RAMPE/INFOMOVILLE et explique le manque de
fiabilit des protocoles utiliss en mode de diffusion (broadcast) sur une liaison radio. Il prsente
ensuite le protocole propos dans la thse conu pour sadapter au type de trafic rencontr dans
lapplication RAMPE/INFOMOVILLE, protocole que nous avons appel RAP pour
RAMPE/INFOMOVILLE Application Protocol ; le chapitre expose aussi les mthodes et le
banc de test dvelopps pour la simulation et lvaluation de RAP sur un canal WiFi rel et sur
un canal simul de Gilbert-Elliot. La simulation sappuie sur le simulateur dvnements discrets
OMNeT++. Les performances obtenues sont compares celles des protocoles classiques.
Le chapitre 4 est consacr au travail effectu sur les aspects localisation et guidage. Il
commence par une courte analyse des besoins des personnes aveugles au cours de leurs
dplacements en termes de localisation et dorientation ainsi que des contraintes dexploitation
dun service de localisation. Il propose ensuite une nouvelle mthodologie de calibration pour
une technique de positionnement par ondes radio WiFi, permettant de renforcer la prcision de
localisation sur certains chemins appels chemins prfrs ; cette mthode est baptise
RWPS (RAMPE/INFOMOVILLE WiFi Positioning System) ; le chapitre dcrit les
exprimentations sur site et les diffrents scnarios tests pour valuer et valider la mthode

Universit Paris-Est
Introduction
propose. Le chapitre se termine par des propositions dintgration de RWPS dans

RAMPE/INFOMOVILLE.
La conclusion rcapitule les contributions de cette thse et propose des perspectives pour
de futurs travaux.
La figure 1 est un synotpique graphique qui prsente le contexte et rsume les contributions de
la thse.
Figure 1- Motivations et contributions de la thse

Universit Paris-Est
Chapitre 1- Les systmes RAMPE et INFOMOVILLE
Chapitre 1
Les systmes RAMPE et INFOMOVILLE
1.1 Introduction
Lamlioration des conditions de vie, laccroissement de lintgration socio-
professionnelle et la promotion dans tous les domaines des personnes handicapes constituent,
depuis plusieurs annes, lobjet de plusieurs recherches, tudes et inventions, ainsi que lobjet de
nouvelles lgislations et obligations pour les tats en gnral et les oprateurs de transports en
particulier [58] et ce, au niveau mondial.
On sintresse dans le cadre de cette thse aux personnes dficience visuelle, aveugles
ou malvoyantes (on utilisera lacronyme PAM pour dsigner les personnes aveugles et
malvoyantes).
Les tudes et exprimentations prsentes dans la littrature sur les dplacements urbains
intermodaux (mtro/bus/tramway) des personnes dficientes de la vision [56, 88, 89, 93, 96,
103, 110] permettent de faire merger leurs stratgies de prparation et surtout de dplacement.
Ces tudes mettent en vidence les principales proccupations et besoins qui peuvent se dcrire
en termes de :
- Scurit : viter les risques de chutes et de collision, en particulier lors de situations
perturbes.
- Localisations : localisation de la personne elle-mme dans son parcours, localisation des
quipements qui jalonnent ce parcours.
- Orientation vers une destination : reprsentation mentale dune trajectoire, fiabilit de la
reprsentation mentale de la situation par rapport la situtation relle dans le parcours.
- Accs linformation : dune part les informations spcifiques aux transports telles que la
position des arrts, les horaires, les lignes passant un arrt, les arrts constituant une
ligne, les informations de perturbation et dautre part les informations non ddies aux
transports et portant sur lenvironnement immdiat telles que les activits disponibles.
- Lassitance lactivit : on se dplace dans un but particulier tel qualler au travail, aller
faire des achats dans un centre commercial et ce but, cette activit peuvent ncessiter des
informations spcifiques.
Lune des principales proccupations des PAM est lamlioration de laccessibilit et de

lamnagement de lespace urbain. La notion d' ambient intelligence introduite par l'union
europenne et les diffrentes tudes, propositions et systmes utilisant des technologies de
communication et de l'information dans le contexte de smart environment , essayent de
rpondre ces proccupations et dassurer une continuit de service [132, 133, 134, 135, 160,
161, 162, 163]. On s'interesse particulirement lamlioration de l'autonomie des PAM au
cours de leurs dplacements.
Lutilisation des transports collectifs et les dplacements dans les ples dchanges
constituent une tche trs complexe gnratrice de stress en particulier dans le cas de
dplacements non familiers et dans les situations imprvues lies aux perturbations des
transports ou aux aleas de lenvironnement urbain pour les transports de surface [5, 8, 48]. Les

Universit Paris-Est
transports de surface (bus, tramway) sont particulirement difficiles utiliser par les PAM en
raison de la multiplicit et la diversit des causes d'incertitude dues entre autres la grande
diversit des configurations dinfrastructures possibles et au fait que ces transports sont
implants dans des zones ouvertes non ddies au transport. En Europe, de nouvelles
rglementations, comme la loi de fvrier 2005 en France sur lgalit des droits et des chances,
imposent aux oprateurs de transport de prendre en compte les besoins spcifiques de ces
personnes et damliorer laccessibilit des moyens de transport. Des tudes ont montr que ces
personnes sont exposes un sur-risque daccidents dans les enceintes de transport collectif :
plus de la moiti des accidents se produisent avec des obstacles suspendus et sur des trottoirs
encombrs dobstacles ou mal entretenus [48].
Plusieurs systmes et outils ont t dvelopps pour assister les PAM et faciliter leur
mobilit et leur autonomie dans les transports collectifs : des dispositifs destins la dtection
dobstacles ainsi que des systmes dinformation et dorientation utilisant diffrentes
technologies (ondes infrarouges, radiofrquences, signaux sonores, interfaces haptiques et
tactiles, systmes de communication et de go-localisation) et disposant de capacit dinteraction
plus ou moins labores. Ces systmes se diffrencient en termes de technologie utilise, mais
aussi dintractivit, de facilit dutilisation, de type dinformations fournies, de disponibilit, de
fiabilit, . Cependant, il nexiste toujours pas de systme dinformation temps rel interactif
et personnalis dploy dans les rseaux de transports collectifs.
Dans ce contexte, le projet RAMPE/INFOMOVILLE a ralis et expriment un

systme interactif dassistance et dinformation auditive destin aux personnes dficience
visuelle, favorisant leur mobilit et autonomie dans les transports collectifs [1, 2, 61, 62]. Son
principe, son fonctionnement et ses diffrents constituants sont dtaills dans ce chapitre. On
dresse auparavant un tat de lart rapide des systmes dassistance la mobilit des PAM.
1.2 Systmes dassistance aux personnes dficientes de la

vision
Plusieurs systmes ont t dvelopps et quelques uns implments pour aider et assister
les PAM au cours de leurs dplacements en ville. Les rptiteurs sonores de feux de circulation
en sont un exemple en France. On pourrait aussi citer de nombreux systmes dassistance aux
PAM mais on se consacre dans le cadre de cette thse et de cet tat de lart plus particulirement
aux systmes dassistance aux voyageurs dficients visuels dans leurs dplacements dans les
transports collectifs.
Ltat de lart suivant rcapitule ces systmes dassistance qui peuvent tre diviss en
quatre catgories :
- Systmes de dtection ou dvitement dobstacles (utiliss dans le dplacement dune

faon gnrale)
- Systmes daide au cheminement et lorientation, ou en dautres termes daide la

localisation et au guidage (utiliss dans le dplacement dune faon gnrale)
- Systmes fournisseurs dinformations : dlivrant des informations lies au transport :

lignes, directions et arrts desservies, parcours, horaires, itinraires, ...etc, cest--dire

Universit Paris-Est
tout ce qui est disponible par affichage visuel pour les voyageurs sans dficience visuelle
(cran-page, afficheurs ddis, plaquettes, mini-plan de rseau, pancartes, etc)
- Systmes de prparation au voyage (utiliss avant le voyage).
En pratique plusieurs systmes remplissent plusieurs de ces fonctions et il est difficile de les
classer dans une seule catgorie.
On peut citer en premier les systmes les plus utiliss la canne blanche et le chien guide qui
constituent une aide lvitement dobstacles et au cheminement ainsi quun moyen
didentification qui peut savrer utile la descente dun mtro par exemple pour inciter le
conducteur maintenir les portes ouvertes plus longtemps. La canne blanche permet de reprer
les obstacles au sol tels que les escaliers, les quais, mais reste insuffisante en ce qui concerne les
obstacles en hauteur [136] ; elle permet de se guider en suivant le bord dun trottoir par exemple.
Dans la premire catgorie, les systmes vont du plus simple aux innovations technologiques
utilisant les ondes radiofrquences ou infrarouges. Citons :
Bandes dveil de vigilance : ce sont gnralement des bandes de polyurthanne colles

et dposes le long des quais de transport ( 50 cm du bord des quais de mtro par
exemple) ou dans les zones dangereuses. Elles sont constitues de plots en relief
dtectables au pied et la canne blanche. Elles servent avertir dun danger tel que la
proximit de la voie de mtro.
Mowat Sensor : Il sagit dun systme de dtection dobstacles contitu dun metteur-
rcepteur ultra-sons et qui se met vibrer lorsque londe ultra-sonore est rflchie par
un obstacle. La frquence des vibrations augmente quand la distance de lobstacle
diminue. Le dispositif fonctionne sur des distances allant de 1 4 mtres [4, 137].
Sonic guide : est lui aussi un dispositif utilisant un principe de sonar pour dtecter les
obstacles mais le systme est intgr dans des paires de lunettes ce qui prsente un intrt
pour la dtection des obstacles en hauteur (dtection difficile pour la canne blanche). Les
caractristiques de frquence et damplitude des ondes rflchies dpendent de la
distance et des proprits physiques de lobstacle qui rflchit les ultra-sons. Le systme
fonctionne sur des distances allant jusqu 6 mtres [4].
Tltact : Tlmtre laser qui transforme les distances en notes musicales ou vibrations
et a une porte de 15 mtres [66, 67].
Parmi les projets et systmes daide au cheminement et lorientation on peut citer:

Bandes de guidage podotactiles : un revtement en relief est plac sur le sol pour former
un chemin que la personne aveugle peut suivre avec une canne. La surface est constitue
de cannelures parallles espaces intervalles rguliers (environ tous les 5 cm) dans le
sens de la marche. La couleur et le contraste du revtement peuvent aussi tre utiles pour
une personne malvoyante.
Cartes tactiles [87]: ce sont des cartes en relief destines aux aveugles. Plusieurs villes
ont expriment le concept (Genve, Paris ). Elles reprsentent gnralement les rues,
les arrts de transports et les plus importants lments topographiques. Elles peuvent tre
accompagnes de fascicule braille avec les noms des arrts, des lignes qui les desservent
et les lieux intressants accessibles par ces lignes. le projet ABAplans (Association pour

Universit Paris-Est
le Bien des Aveugles et malvoyants) consiste en des plans urbains tactiles et interactifs
bass sur des donnes gographiques et accessibles par les aveugles [102].
RIAS (Remote Infrared Audible Signage) Talking Signs : Des metteurs infra-rouge
(IR) sont installs dans diffrents endroits (btiments publics, arrts de bus) et
transmettent priodiquement des messages dinformation vocale. Les utilisateurs
balayent lenvironnement avec leur rcepteur et linterception dune mission
infrarouge, le message vocal est restitu sur le haut-parleur du rcepteur. Lutilisateur
peut ainsi dcouvrir son environnement proche et tre guid vers lmetteur [5, 6, 14, 59,
60, 111]. Dans la mme ligne de systmes on peut citer les projets OPEN (Orientation
by Personal Electronic Navigation) [69, 70], Pathfinder [69], BOS (Blind Orientation
System) [109], EW (Easy Walker) [109], BILOS (Blind Information Localisation and
Orientation System) [8, 57].
BlueEyes [7]: ce systme a pour objectif de "faciliter les dplacements dans le mtro et
le RER". Le nom BlueEyes est inspir du mot Bluetooth dsignant une norme de
communication sans fil fonctionnant faible distance (10 mtres). Les composants du
systme BlueEyes sont :
o Un rseau de balises Bluetooth couvrant lensemble dune station mtro/RER
o Un serveur de base de donnes sur lequel sont dfinis les positions des balises, les
messages vocaux, les plans de stations
o Une application sur tlphone portable Bluetooth
Le principe est le suivant :
o Lutilisateur slectionne lapplication BlueEyes sur son tlphone portable

o Il choisit le chemin dsir (stations de dpart et darrive) via le clavier du
tlphone ou oralement
o Lapplication BlueEyes balaie lenvironnement la recherche des balises. Une
fois quune balise est repre, un accs la base de donnes BlueEyes a lieu ce
qui permet de calculer le trajet choisi, de rcuprer les rfrences de la balise et de
calculer la position de lutilisateur et son orientation.
o Le guidage commence ds que lutilisateur arrive la station de dpart et consiste
en une succession de messages vocaux et/ou graphiques indiquant les directions
prendre, des confirmations de bon chemin et des annonces derreurs.
NAVWORKS : La socit CECIAA a dvelopp le systme NAVWORKS, un systme

portatif dassistance la navigation des aveugles. Le systme utilise un module
Bluetooth GPS et permet de se guider dans la rue [11]. Une exprimentation a t
ralise Paris dans laquelle les donnes cartographiques de la RATP pour les arrts des
lignes de bus 92 et 37 et des bouches de mtro sur le trajet ont t enregistres dans le
systme. Le but est de guider la personne depuis un arrt de de dpart vers larrt
darrive choisi. Un moteur de calcul ditinraires cherche la route la mieux adapte
prsentant un minimum de carrefours ou dobstacles franchir. Cette route choisie est
nonce auditivement lutilisateur.
Projets RFID UCODE Tokyo et projet SESAMONET en Italie : Le projet IT barrier

free project lanc Tokyo en 2003 et pilot par le professeur Sakamura avait pour but
de dvelopper un dispositif permettant aux aveugles de sauto-guider laide dtiquettes
RFID. Il sagit de carrelages intgrant des tiquettes didentification sans contact (RFID)
(baptises UCODE) et destines tre lues par la canne d'un aveugle relie un

Universit Paris-Est
dispositif de lecture "Communicator". Ces tiquettes RFID sont dposes sur le sol pour
marquer les quais du mtro, les alles des supermarchs, etc. Le lecteur RFID port par
lutilisateur sur une canne blanche lit les informations contenues dans les tiquettes et les
nonce vocalement son porteur (dtection de carrefour, dune marche, etc) [138, 139,
140]. Ce mode de guidage a t dploy sur le campus de l'Universit de Tokyo.
Le projet SESAMONET (SEcure and SAfe MObility NETwork : a navigation aid for
blind people) en Italie a un objectif assez proche [72]. SESAMONET utilise une grille
dtiquettes RFID sous la chausse pour guider les personnes. Il fournit de linformation
sur les sites proximit. Le systme comprend 4 lments : une grille dtiquettes RFID
sous la chausse (enterres environ 4 cm), un dispositif (type PDA) port par
lutilisateur avec des oreillettes Bluetooth, une canne qui sert de lecteur RFID (le lecteur
lit le numro didentification des tiquettes et envoie linformation par Bluetooth au
PDA), un serveur central de navigation. Le PDA reoit et traite la suite de numros des
tiquettes et des donnes de navigation. Il envoie ensuite des messages audio de
navigation lutilisateur en les transmettant aux oreillettes bluetooth. Les donnes de
navigation sont tlcharges priodiquement partir du serveur central par une
connexion radio WiFi ou GPRS. Le serveur stocke les informations : numros et
positions des tiquettes, informations sur lenvironnement. Les donnes sont organises
en cellules. Quand lutilisateur atteint la frontire dune cellule, les nouvelles donnes
sont transmises automatiquement. Dans la mme type de projet, on peut citer le projet
Drishti de luniversit de Floride [141].
RNIB REACT (Royal National Institute for the Blind- Rapid Emergency Alert
Coordination and Targeting) : des arrts de bus parlants (en anglais talking bus
stops ) ont t introduits dans les villes de Brighton et Hove en Angleterre en 2007
[107, 108, 142]. Ces arrts sont quips des systmes RNIB REACT [120, 129] qui
annoncent les informations temps rel lies aux trajets des bus, permettant aux PAM de
savoir quel arrt de bus ils sont, quels sont les bus lapproche, leur temps darrive,
Les bornes REACT sont actives par des dispositifs ports par les PAM et qui
utilisent une mthode de synthse de voix pour couter les informations transmises.
DANAM (Dispositif dAssistance la Navigation pour personnes Aveugles dans les

couloirs du Mtro)[94] : il sagit dun projet financ par lagence nationale de la
recherche dans le cadre du programme PREDIT en partenariat avec la RATP, le
laboratoire THIM (Technologies, Handicaps, Interfaces, Multimodalits) de luniversit
Paris 8, la socit Robosoft PGES (Perception and Guidance Embedded Systems) et le
laboratoire LIST (Laboratoire dIntgration des Systmes et des Technologies) du CEA
(Commissariat lEnergie Atomique). Lobjectif de ce projet est de guider les PAM dans
les couloirs et stations de mtro du rseau RATP tout en dispensant de tout autre
dispositif complmentaire plac dans linfrastructure (bornes, tirages de cbles, nergie).
Il est bas sur un systme de localisation tirant partie la fois de capteurs dorientation
ports par la personne, dun algorithme de navigation lestime intgr sur un
microprocesseur, dune cartographie de lieux et des facults de perception de
lutilisateur.
ANGEO : le projet de recherche Binaur est devenu le projet industriel Ango de la

socit Angeo Technology essaimage de lentreprise Navocap Toulouse [97]. Ango
est une plateforme d'assistance et d'aide l'orientation destine aux malvoyants et aux
aveugles. Il comprend un quipement embarqu utilisant les signaux GPS et EGNOS

Universit Paris-Est
(ceci assure une prcision de 5 mtres), dune interface homme-machine base sur la
reconnaissance et la synthse vocale, dune plate-forme de services et d'assistance
multilingues accessible grce la liaison GSM/GPRS intgre et qui permet labonn
de disposer d'une assistance personnelle ou technique (calcul d'itinraire, problme
d'utilisation), dun logiciel de planification ditinraires multimodal intgrant des
portions pdestres et en transports en commun, dun portail Internet communautaire
ouvert aux associations et aux particuliers et dune fondation gre par les abonns et qui
permettra aux plus dmunis d'avoir accs aux services d'ANGEO [97].
PAVIP (Personal Assistant for Visually Impaired People) [105]: produit de la socit
suisse Bones dvelopp spcifiquement pour les PAM, en collaboration avec lUnion
Centrale Suisse pour le bien des aveugles (UCBA). Il est constitu de rcepteurs de la
taille dune carte de crdit qui comprennent cinq touches et de petits metteurs placs
dans les btiments et dans les transports publics. Les metteurs indiquent aux PAM la
direction de leur destination et la distance qui les en spare via une mthode de synthse
vocale du rcepteur PAVIP. Si cette destination est un moyen de transport public, PAVIP
indique l'heure d'arrive d'un tram, la prochaine station, l'ouverture de la porte et d'autres
informations.
SWAN (System for Wearable Audio Navigation) [98, 143] : ce systme amricain dont
le but est daider les PAM naviguer dans des environnements non familiers, consiste en
un ordinateur portable, un rcepteur GPS, des camras et plusieurs capteurs; le
composant principal sont les couteurs permettant la perception des balises radio 3D ; les
objets qui entourent la PAM (btiment, parc, banc, etc) sont reprsents par des sons
uniques. La position et lorientation de la PAM sont dtermines, et des balises de
guidage sont prsentes sur le trajet jusqu la destination.
Personal Guidance System (PGS) : ce systme a t dvelopp dans les annes 1990 par
les professeurs Loomis, Glatzky, Golledge, Speigle et Tietz [49, 90, 104]; il consiste en
un rcepteur GPS prcisant la position et lorientation de la PAM, une base de donnes
spatiale (GIS-Geographic Information System) et dune interface homme-machine. Les
informations sur la position de la PAM lui sont nonces via une oreillette, puis il est
guid en lui nonant des informations utiles sur son parcours (les endroits, les milieux et
les objets qui lentourent etc). Des tudes sur lintrt de la spatialisation sonore pour
le guidage ont t ralises.
Systme Trekker GPS de la socit VisuAide qui est un GPS parlant sur un ordinateur
de poche iPAQ de Hewlett-Packard [100], Maestro [101] qui a fait suite au systme
Trekker GPS et qui utilise un systme de synthse de voix et une membrane tactile de
clavier installe au-dessus de lcran du PDA HP, Trekker Breeze de HumanWare [50],
StreetTalk de Freedom Scientific [148, 149], le systme bas sur les dispositifs Symbian
[153].
Le projet BIOVAM- Besoin en Information et en Orientation des Voyageurs Aveugles

ou Malvoyants dont le but tait didentifier les besoins des aveugles dans le domaine de
dtection dobstacles, de lorientation et de prise dinformation, de lutilisation des
moyens de transport [8], a valu les deux types de systmes dvelopps lpoque du
projet BIOVAM pour lassistance des aveugles sappuyant respectivement sur des
balises infra-rouge (IR) et radiofrquences (RF). Les systmes IR ont t considrs

Universit Paris-Est
difficiles utiliser dans les milieux encombrs [1, 8]. Quant aux systmes RF, ils sont
plus simples mais pas assez efficaces en termes de guidage.
D. Eddowes et J. Lopez Krahe ont travaill sur un projet de reconnaissance des feux
pitons en environnement urbain avec un assistant personnel [130, 159]; lapplication est
implmente sur un ordinateur de poche de type PDA avec une camra vido incorpore.
Linterprtation est base sur lanalyse des scnes prises par la camra. Dautres
fonctionnalits adaptes aux personnes aveugles sont aussi intgres dans le systme
(rpertoire, gestion de rendez-vous), par reconnaissance des empreintes vocales.
Les systmes fournisseurs dinformations comportent les systmes qui, un point

darrt, fournissent des informations lies au transport : nom de la station, direction, lignes,
parcours, destinations desservies, horaires, vnements, ventuelles modifications et
perturbations Gnralement, la synthse vocale de ces informations constitue une mthode
perceptive substitutive une vision dficiente ou rduite (nonciation des informations
gnralement perues par les personnes bien voyantes sur des panneaux daffichage papier ou
lectronique via un haut-parleur ou par le biais dun dispositif individuel port par la personne
aveugle). On liste ici quelques uns des projets en cours et des systmes existants.
Systme sonore de la Rpublique Tchque (systme Tyfloset et projet NEV1) : En

Rpublique Tchque, la compagnie Apex LTD a dvelopp le systme Tyfloset facilitant
laccs des malvoyants aux transports publics. Les tramways et les bus sont quips par
des rcepteurs RF. Un passager malvoyant qui est un arrt de transport public dispose
soit dun transmetteur 3 boutons intgr dans sa canne soit dun transmetteur
indpendant dans un botier 6 boutons. Le dispositif lui permet dactiver le haut-parleur
extrieur du vhicule qui lui nonce sa route et sa destination [84]. Le projet NEV1 est
une extension de Tyfloset. Les dveloppements de ce projet se sont drouls de janvier
2005 mai 2007. Ils ont t financs par le ministre des transports tchques. Les
partenaires de ce projet taient les socits APEX, dj acteur du systme Tyfloset, la
socit electronics for transportation (e4t) et le centre de recherche sur les transports.
Lobjectif du projet tait de mettre en place un systme audio de rfrencement
gographique. Ce systme doit permettre de se connecter diverses sources
dinformation telles que tableaux horaires, point darrts, plans, et de fournir de
linformation et des consignes de guidage sous forme vocale partir de choix de
parcours fait par lutilisateur. La conversion audio des informations de guidage et
dorientation a pos des problmes de mthodologie important.
NOPPA (VTT en Finlande) : le projet NOPPA- systme de navigation personnel

(Personal Navigation and Information System for Users of Public Transport) est support
par le programme HEILI dinformation aux voyageurs du ministre des transports et des
communications en Finlande a pour but daider les malvoyants dans les rseaux de
transport public. Noppa sappuie sur des composants et services disponibles de
navigation personnelle. Lutilisation des bases de donnes de services publics sur
internet assure une information jour. Lassociation dinformations voyageurs provenant
de diffrentes sources et le dveloppement dinterfaces dusage gnral sont des
caractristiques du projet. Noppa offre pour le moment un service de planification de
trajets et de navigation Helsinki, Espoo, Vantaa, Kauniainen and Tampere. NOPPA a
pour objectif doffrir des services dinformations locales et dinformations sur les
transports, des services de navigation lintrieur et lextrieur des btiments, de

Universit Paris-Est
communication avec des serveurs vocaux et ventuellement dintgrer des dispositifs de

dtection dobstacles par camra vido. Le principe consiste utiliser un serveur
dinformation auquel le tlphone portable de la PAM est connect via GPRS. Le
serveur dinformation effectue les recherches internet et transmet linformation
ncessaire vers le tlphone sous forme vocale. Lutilisateur peut tre aussi guid en
utilisant le GPS [13].
Systmes EO-guidage [10] et ESIUM [73] : Ce sont deux systmes assez proches qui
ont commenc comme des systmes rptiteurs de feux de circulation. Le systme EO-
guidage de la socit EO-EDPS (Etudes Dveloppements Produits Services) utilise des
tlcommandes RF. La tlcommande permet de faire sonner une borne situe un arrt
de bus et ventuellement de recevoir un message dinformation vocal indiquant le nom
de larrt et les lignes associes. La socit ESIUM dveloppe un systme assez
similaire. En comparaison avec dautres systmes existants pour la mme fonction,
lintrt annonc du systme rside dans le fait que lappareil se dclenche en fonction de
lorientation de la personne et lui dlivre un message personnalis adapt sa situation et
sa demande. Il devrait permettre lusager de limiter lactivation sonore la traverse
envisage et ainsi de minimiser les confusions lies au dclenchement simultan de
plusieurs feux.
Ubibus: Projet dvelopp lINRIA - Institut National de Recherche en Informatique et

en Automatique. Il a pour but daider les malvoyants prendre le bus et utilise un simple
assistant personnel [68]. Il comporte trois entits : l'usager, l'abribus, et le bus. L'arrt de
bus est quip d'une bulle d'information Bluetooth ou WiFi. Lutilisateur donne
oralement une information son PDA et partir de ce moment, le PDA se met
chercher les ondes Bluetooth ou WiFi Ubibus proximit. Lorsque l'usager s'approche
de lubibus, les deux quipements sinterconnectent : le PDA indique quel bus l'usager
souhaite prendre tandis que l'abribus indique le temps d'attente que le PDA annonce
vocalement. Ensuite, il se passe la mme chose entre l'abribus et le bus. Lorsque le bus
sapproche de labribus, les deux sinterconnectent : l'abribus envoie un signal darrt,
exactement comme si quelqu'un l'intrieur du vhicule demandait l'arrt. Cette
information est rpercute l'usager, via son PDA, lui indiquant que le bus souhait est
arriv.
ACTITAM : solutions dveloppes par la socit Phitech pour linformation et le

guidage des personnes dficientes visuelles dans les tablissements recevant du public
(htels, restaurants, centres commerciaux, rseaux de transport [95]. LActiTam-
afficheur par exemple rend accessible, aux PAM disposant du botier ActiTam, les
informations prsentes sur un afficheur. Les informations crites sont traduites et
transmises par radio au botier port par lutilisateur. LActiTam-Rseau-Htel consiste
en la mise en place dans un htel, d'une ou plusieurs balises Phitech permettant la PAM
muni d'un botier ActiTam, de se reprer, de pouvoir disposer de faon discrte
d'informations de guidage et de trouver la rception, le bar, les toilettes, l'ascenseur, la
chambre, etc.
AudioTransantiago [99]: logiciel dvelopp luniversit du Chili Santiago. Les

informations contextuelles chaque arrt de bus des routes de Transantiago sont
sauvegardes dans des fichiers XML sur le PDA de la PAM et celui-ci pourra y naviguer
par le biais du PDA avec un logiciel de synthse vocale.

Universit Paris-Est
Pour les systmes daide la prparation du voyage, on peut citer les outils de
consultation de sites web sur les transports et le tourisme [56], les interfaces logicielles de
lecture dcran qui fournissent les informations de la page web par une transcription sonore ou
braille (Braillesurf, MozBrailleetc). Des solutions concernant la billeterie ont aussi t
proposes comme le projet europen Esprit MASK dveloppant une borne de rservation et de
transaction de billets interface vocale utilisable par les PAM.
1.3 Prsentation et historique de RAMPE/INFOMOVILLE

RAMPE [1, 2, 3, 19, 61, 62] ou Rfrentiel d'assistance aux personnes Aveugles
pour leur Mobilit dans les transports publics et les Ples d'Echanges , est un projet qui a
dbut en Janvier 2004 et sest achev en 2007. Lobjectif tait de concevoir et de dvelopper,
grce aux nouvelles technologies de communication et dinformation, un quipement intractif
pour assister les personnes malvoyantes dans les transports publics, en particulier les rseaux de
bus. Le choix des rseaux de bus se justifie par le fait quil sagit dun mode de transport
particulirement difficile utiliser pour une PAM cause de la multiplicit et diversit des
causes dincertitude (prsence et localisation des stations, informations lies au transport,
configuration du rseau, trafic, ...) [1, 112]. Il a t support par le ministre des transports dans
le cadre du programme PREDIT - Programme franais de Recherche, d'Exprimentation et
d'Innovation dans le domaine des Transports terrestres, sous le thme gnral des services de
mobilit et daccessibilit pour les personnes mobilit rduite.
Il a associ trois partenaires complmentaires : ESIEE-Paris, la socit Lumiplan et Grard Uzan
du LEI. ESIEE Paris , cole Suprieure dIngnieurs dans le domaine des sciences et
technologies de l'Information et de la Communication, qui a pilot le projet, a contribu aux
spcifications techniques de lapplication et du systme dinformation et a dvelopp
lapplication sur le dispositif port par la PAM (le PDA) ; LUMIPLAN, socit spcialiste des
produits et services d'information dans les transports, a dvelopp lapplication sur la borne et a
contribu limplantation aux arrts dans la dernire phase du projet. Le LEI, Laboratoire
dErgonomie Informatique de lUniversit Paris 5, a effectu lanalyse des besoins et contribu
aux spcifications principalement sur linterface Homme-Machine (MMI pour Man Machine
Interface).
Le systme RAMPE fournit les informations suivantes:

Inventaire des stations proximit de la personne non-voyante
Reprage de la position spatiale des stations par la personne non-voyante
Inventaire des lignes desservies par ces stations, itinraire de chaque ligne
Horaires et perturbations ventuelles,
On peut classer ces informations en trois catgories : des informations structurelles
(identification des arrts, lignes, horaires, etc.), des informations temporaires (changement
dhoraires, dtournement, etc) et des informations durgence (arrive dun bus).
Le projet INFOMOVILLE, Environnement temps-rel pour lINFOrmation,

lorientation et la scurit des voyageurs handicap sensoriel (visuel ou auditif) au cours de
leurs dplacements dans les transports collectifs, les ples dchanges et de faon plus gnrale
pour la MObilit en VILLE , fait suite au projet RAMPE [113]. Tandis que le projet RAMPE
tait focalis sur lapproche dun point darrt et sur linformation utile avant lentre dans un
vhicule, INFOMOVILLE largit le champ de RAMPE en termes de services rendus,

Universit Paris-Est
dutilisateurs potentiels, dintgration de nouvelles informations, dergonomie et dinterface

homme-machine, de technologie de communication et de localisation. INFOMOVILLE est
support par lagence nationale de la recherche (ANR) dans le cadre du programme PREDIT.
INFOMOVILLE a dbut en mai 2007 et devrait se terminer en mai 2010 par une
exprimentation dans le rseau de transport lyonnais.
1.3.1 Constituants et Architecture

Les constituants de RAMPE/INFOMOVILLE, son architecture et ses diffrentes
connexions sont repsents sur la figure 2 suivante [1] :
Figure 2- Architecture gnrale du systme RAMPE/INFOMOVILLE
Les constituants de RAMPE/INFOMOVILLE sont les suivants :
Un dispositif de type ordinateur de poche (PDA) port par la PAM ; ce PDA avec
lapplication RAMPE/INFOMOVILLE dispose dune interface de communication
sans fil WiFi, dune interface homme-machine utilisant une synthse vocale et des
commandes par boutons. Lapplication sur PDA gre trois acteurs : lutilisateur
travers linterface homme-machine, le rseau travers la carte rseau WiFi et la base
de donnes dinformations lies aux transports (cette base de donnes est disponible
au niveau de la borne et est consulte par la PAM). Les interactions entre ces acteurs
se font par une machine dtats finie (FSM pour Finite State Machine) qui comprend
un tat initial (tat didentification des arrts proximit) et trois autres tats (tat de
choix dun arrt, tat de reprage de la position de larrt et tat de navigation dans la
base de donnes). Ces tats sont dtaills dans le paragraphe 1.3.2 sur le principe et
fonctionnement de RAMPE/INFOMOVILLE.

Universit Paris-Est
Interface
homme- Rseau
machine
Machine
dtats
finis
Base de
donnes
Figure 3- Structure de l'application sur PDA
Des bornes installes aux arrts de bus. Ces bornes sont quipes de points daccs
WiFi leur permettant de communiquer avec le PDA et dun processeur avec un
systme client/serveur dinformations connect au point daccs. Elles constituent les
nuds dinformation : elles reoivent ces informations dun systme central et les
distribuent aux PDAs. Elles intgrent aussi un haut-parleur qui carillonne afin de
permettre la PAM de reprer auditivement la position de la borne
Le rseau de transport avec son systme dexploitation et dinformation voyageurs
(SAEIV : Systme daide lexploitation et linformation voyageurs). Il comprend
un systme central qui est connect aux bornes installes dans les points darrt et aux
vhicules (bus, tramway) par diffrents moyens de communication. Il envoie
linformation aux bornes les informations sur les horaires, les lignes desservies, les
parcours, ainsi que les informations immdiates temps rel (accidents, changement
dhoraires, vhicule lapproche, etc) [1]. Linformation peut tre thorique ou temps-
rel (horaires thoriques, avances/retards). La position des vhicules peut tre suivie
par diffrents systmes de positionnement comme le GPS.
1.3.2 Principe et fonctionnement

La borne installe dans la station de bus rcupre, du systme central du rseau de
transport, les informations disponibles concernant larrt de bus : lignes, itinraires, horaires
Ces informations spcifiques de la station sont stockes dans une base de donnes.
Le point daccs WiFi embarqu dans la borne envoie priodiquement son identifiant - son SSID
(cf. chapitre 2) dont la syntaxe est spcifique au rseau RAMPE/INFOMOVILLE ; elle est de la
forme RAMPEnom_du_point_darrt/direction .
Sur le PDA tourne lapplication RAMPE/INFOMOVILLE. Un soin particulier a t port la

conception de linterface homme-machine. Elle est ralise par une interface de commandes
utilisant les touches du PDA et par une synthse vocale pour linformation du PDA vers
lutilisateur. Les fonctions des touches de commande se reconfigurent automatiquement selon
ltat de lapplication avec un souci de rendre la manipulation la plus intuitive possible. On

Universit Paris-Est
distingue deux modes de fonctionnement des touches du PDA : le mode normal et le mode
urgent pour lesquels la figure 4 illustre les fonctions des touches. Le premier modle de PDA
utilis pour limplantation de lapplication RAMPE/INFOMOVILLE tait lorganiseur iPAQ
4150 de Hewlett-Packard. La figure 4 prsente la disposition des touches de ce PDA ;
ultrieurement lapplication a t implante sur dautres types de PDA, mais les commandes par
boutons et les modes de fonctionnement sont rests identiques dans le principe, mme si la
forme et la position des touches a pu changer dun dispositif lautre.
Figure 4- Les boutons et les deux modes de fonctionnement du PDA
Dans le mode normal, Le bouton Stop sert terminer lapplication

RAMPE/INFOMOVILLE ; les boutons Silence mettent lapplication en mode silence (la
synthse vocale est interrompue mais le programme continue tourner ; lattention de
lutilisateur nest attire quen cas de messages urgents pour lesquels le PDA sort du mode
silence). Les boutons Acquittement (ACK pour Acknowledge) permettent dacquitter ou
deffectuer une slection la vole dans une liste de propositions enonces vocalement :
lassociation un borne, la demander quun carillon soit mis depuis cette borne (pour pouvoir
reprer sa position), la navigation dans la base de donnes. Lappui sur les touches ACK permet
donc ainsi de faon intuitive de passer dun tat lautre de la machine dtats.
Dans le mode urgent, tous les boutons se transforment en Acquittement ; Le mode urgent
correspond une situation dans laquelle la borne diffuse un message urgent tous les
utilisateurs (arrive dun bus par exemple). Ce message est rpt jusqu son acquittement par
lutilisateur et pour simplifier sa tche et viter de le perturber, tous les boutons se transforment
en boutons ACK [3] avant de revenir leur fonctionnement en mode normal aprs
lacquittement.
Lutilisation des touches du PDA en mode acquittement permet de synchroniser ltat de
lapplication avec la situation de lutilisateur.
Lapplication RAMPE/INFOMOVILLE du PDA surveille la prsence des points daccs ; ds

quelle dtecte un arrt, elle en informe lutilisateur en produisant un petit bip. Lutilisateur peut
demander sinformer sur les noms et les directions des arrts dtects (informations contenues
dans le SSID diffus) en appuyant sur un bouton ACK de son PDA ; les diffrents arrts sont
noncs lun la suite de lautre. La PAM peut choisir de se connecter lun de ses arrts par un
appui sur une touche du PAD au moment de lnonciation vocale du nom de larrt choisi.
Cette demande de connexion se traduit dun point de vue informatique par une requte
dassociation (requte envoye pour se connecter un rseau WiFi) (cf. chapitre 2) qui est

Universit Paris-Est
envoye par le PDA vers le point daccs, la borne fournit au PDA une adresse IP lui permettant
de se connecter au rseau et par la suite dtre capable denvoyer et de recevoir des trames de
donner pour intragir avec la borne [3, 9].
Figure 5- Association du PDA au point d'accs
La borne commence alors mettre des carillons sonores permettant la PAM de reprer sa
position ; la PAM peut actionner les touches ACK du PDA pour refaire carillonner la borne.
La base de donnes est ensuite tlcharge sur le PDA afin de permettre la PAM dy naviguer
et de consulter les informations disponibles lies son parcours ; ces informations sont nonces
par le systme de synthse de la voix intgr dans le PDA.
Figure 6- Sonnerie de la borne et tlchargement de la base de donnes
La navigation dans la base de donnes comporte trois niveaux:

- Niveau 1 : liste des lignes disponibles passant larrt et nombre de minutes avant le
prochain passage.
- Niveau 2 : pour une ligne donne : ensemble des arrts appels squelettes sur cette ligne.
La notion darrt squelette est une notion arbitraire dfinie a priori et correspond des
arrts jugs importants (correspondances par exemple).
- Niveau 3: liste de tous les arrts disponibles depuis la station squelette prcdemment
choisie.
Le passage dun niveau un autre se fera en appuyant sur les boutons ACK du PDA comme
montr sur la figure 7. Il est possible de revenir en arrire dans les niveaux laide dun appui
long sur les touches de commande ACK.

Universit Paris-Est
Figure 7- Les trois niveaux de navigation dans la base de donnes
Il arrive que les informations prsentes dans la borne changent (mises jour par le SAEIV) ou
quun vnement urgent (accident, retard, arrive de bus) survienne. Pour en avertir lensemble
des utilisateurs associs la borne, la borne envoie des trames spcifiques de notification
dinformations urgentes. Pour un message urgent, le PDA reoit la trame correspondante,
lapplication interrompt la navigation dans linterface utilisateur et informe immdiatement
lutilisateur du message urgent par synthse vocale. Sil sagit dun rafrachissement des
informations prsentes dans la base de donnes, le PDA reoit la trame correspondante,
tlcharge de nouveau la base de donnes, et informe lutilisateur des nouvelles informations
disponibles. Les messages urgents doivent tre acquitts par lutilisateur, sinon ils sont rpts
en boucle en attendant quils soient acquitts.
Rcapitulons les quatre tats correspondants aux quatre phases dutilisation de lapplication
RAMPE/INFOMOVILLE par le schma de la figure 8. Il est possible de revenir en arrire vers
ltat prcdent laide dun appui long sur les touches de commande ACK.
Etat 0
Identification
des arrts
Etat 3
Etat 1
Navigation
Choix de
dans la base
larrt
de donnes
Etat 2
Reprage
spatial/
approche
Evolution normale de RAMPE/INFOMOVILLE

Dtournements possibles
Figure 8- Les quatre phases d'utilisation de RAMPE/INFOMOVILLE [2]
Exprimentation de RAMPE/INFOMOVILLE sur le rseau de Transport en

Commun Lyonnais (TCL) :
Une exprimentation du systme RAMPE [106, 144, 145] a t mene en partenariat

avec le SYTRAL (SYndicat mixte des Transports pour le Rhne et l'Agglomration Lyonnaise-

Universit Paris-Est
autorit organisatrice de transports (AOT) de Lyon) et Keolis (socit franaise de transports

publics de voyageurs qui appartient au groupe SNCF) sur le rseau TCL en Avril 2007 pour une
dure de deux semaines. Deux types de dispositifs utilisateurs ont t expriments et compars
: un PDA et une tlcommande permettant de dclencher la sonnerie de la borne installe dans la
station de bus et disposant dun haut-parleur intgr. Les scnarios de lexprimentation ont t
labors de faon comprendre une correspondance et de permettre de tester deux parcours
symtriques avec le PDA et la tlcommande. Le parcours choisi avait la forme dune huit et
comprenait 4 lignes de bus et une correspondance centrale situe dans un ple dchanges. Des
observations ergonomiques, des mesures des niveaux sonores, doccupation spectrale et de
charge du rseau WiFi ainsi que des enregistrements vido ont t raliss. la fin de chaque
test des questionnaires ont t recueillis. Les tests ont t effectus avec 23 sujets aveugles et 8
sujets voyants. Lobjectif tait dvaluer lutilisabilit et la pertinence des deux dispositifs (PDA
et tlcommande) en prenant comme indicateurs les dures, le nombre dinterrogations pour
lidentification des arrts, la localisation et lorientation des sujets vers les bornes, Les
exprimentations ont montr que les deux dispositifs permettent aux personnes dacqurir une
bonne reprsentation mentale du parcours. Le PDA permet une meilleure efficacit dans la
plupart des situations et na pas pos de problme dutilisation mme aux personnes peu
technophiles. Par ailleurs, la dispersion des rsultats entre sujets est plus faible pour le PDA.
Enfin, lcart de performances entre les rsultats des sujets aveugles et ceux des sujets voyants
se rduit et converge fortement lorsque lon passe dune situation simple (simple arrt) celle
dun ple dchanges.
1.4 Simulation de RAMPE/INFOMOVILLE dans

lenvironnement OMNeT++
Dans ce paragraphe, on prsente le travail effectu pour dvelopper une simulation de
haut niveau du fonctionnement de lapplication RAMPE/INFOMOVILLE en utilisant le
simulateur OMNeT++ (Objective Modular Network Testbed in C++) (linstallation de ce
simulateur est dcrite dans lannexe B).
1.4.1 Introduction sur OMNeT++

OMNeT++ est un logiciel libre destin la simulation dvnements discrets crit en
langage objet C++. Il a t developpe par Andras Varga, chercheur l'universit de Budapest
[21]. Il a t conu pour la simulation des rseaux informatiques, des systmes multiprocesseurs
et d'autres systmes rpartis. Il est utilis par de nombreux groupes de recherche pour
l'valuation et lestimation des performances dun rseau de tlcommunication. Il est utile pour
l'illustration, la correction, l'valuation et l'amlioration des performances. Il fournit un ensemble
d'outils qui aident modifier ou mettre en application de nouvelles caractristiques d'une
manire simple. Plusieurs exemples de modles peuvent tre simuls avec OMNeT++ [22] ; on
peut citer :
Protocoles de transmission : Protocoles de la couche Physique/Liaison de Donnes :

Ethernet, token ring, FDDI, etc ; Protocoles de couches plus leves : IP, TCP, X.25
L2/L3, etc ; Types d'application de rseau: E-mail, NFS,
Algorithmes de routage
Rseaux informatiques et Modles de trafic : files d'attente etc...
Multiprocesseur et systmes rpartis

Universit Paris-Est
Systmes administratifs
...
Les composants dOMNeT++
Librairie de simulation (noyau ou kernel)

Compilateur pour le langage de description de topologie (NED pour Network
DEscriptor)
Editeur graphique de rseau (GNED pour Graphical NEtwork Descriptor)
Interface Graphique (GUI pour Graphical User Interface) pour l'excution de simulation
(appele Tkenv)
Interface ligne de commande pour l'excution de simulation (appele Cmdenv)
Outil de traage de vecteur graphique (Plove)
Divers outils (outil de gnration de nombres alatoires, outil de cration de fichier
makefile, etc...)
Langage de description de rseau (Network DEscription (NED)) et ses composants
Un rseau est form de "noeuds" relis par des "liens". Les noeuds reprsentent les blocs
(modules simples ou composs), tandis que les liens reprsentent les canaux, raccordements, etc.
La faon dont des lments fixes (c.--d. noeuds) dans un rseau sont relis ensemble s'appelle
la topologie.
OMNeT++ utilise le langage NED qui facilite la cration, ldition, et la reprsentation
graphique dun certain rseau simuler. Il suit une structure hirarchique tenant compte de
diffrents niveaux d'organisation. Un nud par exemple peut tre structur selon les diffrentes
couches OSI dont il se compose : couche physique, liaison de donnes, rseau, transport,
application De mme, chaque couche peut tre structure selon les applications ou protocoles
qui tournent au niveau de cette couche.
Les fichiers de description de rseau ont un suffixe .ned. Le compilateur NEDC traduit
les descriptions de rseau en code C++. Puis, ces descriptions seront compiles par le
compilateur C++ et incorpores dans la simulation excutable. Donc une description NED peut
contenir les composants suivants, dune faon et en nombre arbitraires:
Les dclarations d'Importation
Dfinitions de Canaux
Modules Simples et Composs
Interface utilisateur
L'interface utilisateur d'OMNeT++ concerne l'excution de simulation. Elle permet

l'utilisateur de lancer et terminer des simulations et de changer des variables lintrieur des
modles de simulation. L'utilisateur peut examiner et corriger la simulation avec une interface
graphique puissante.
Actuellement, deux interfaces utilisateur sont soutenues :
Tkenv (Tk-based graphical, Windowing User Interface): cest une interface graphique
qui permet le traage , la correction et lexcution de simulation. Elle a la capacit de

Universit Paris-Est
fournir une image dtaille de l'tat de la simulation un point quelconque pendant

l'excution. Caractristiques de Tkenv:
Fentre spare pour chaque module

Les messages programms peuvent tre observs dans une fentre pendant que la
simulation progresse
Excution d'vnement-par-vnement
Animation de l'excution
Fentres pour examiner et changer des objets et des variables dans le modle
Affichage graphique des rsultats de simulation pendant l'excution
La simulation peut tre remise en marche
La figure 9 prsente linterface Tkenv.
Figure 9- Tkenv avec OMNeT++
Cmdenv (Command-line User Interface for Batch execution) : conue principalement

pour l'excution en batch. C'est une interface par ligne de commande portative, petite et
rapide. Cmdenv excute simplement toutes les simulations runs qui sont dcrites dans
le fichier de configuration.
Diffrents types de fichiers
Les fichiers prsents dans une simulation OMNeT++ :
- Fichier NED pour dcrire le modle de simulation

- Fichier de configuration omnetpp.ini pour linitiation des variables et des paramtres
- Fichier C++ pour initialiser les diffrents modules et dcrire leur fonctionnement
- Fichier de messages .msg dcrivant les diffrents messages changs entre les modules
- Fichier .h pour la dclaration des classes et variables qui seront utilises dans le fichier
de simulation C++
- Fichiers XML pour la reprsentation des donnes et scnarios de simulation

Universit Paris-Est
1.4.2 Simulation de RAMPE/INFOMOVILLE

Pour la simulation du fonctionnement de RAMPE/INFOMOVILLE, cinq fichiers ont t
crs [9]:
- RAMPE.ned: dcrivant larchitecture de RAMPE/INFOMOVILLE et ses diffrents

composants : le point daccs qui est install dans larrt de bus, le processeur
client/serveur embarqu dans la borne de larrt de bus (et qui communique avec le
systme central propre au rseau de transport), le PDA port par la PAM (not blind
dans la figure 10), et la PAM lui-mme. Le PDA est un module OMNeT++ compos de
4 boutons: Acquittement, Silence, Arrt et Interface. Cette interface
reprsente linterface homme-machine qui va interagir avec la PAM et lui noncer
vocalement les informations lies son parcours. A chaque message reu, la PAM peut
appuyer sur lun des boutons du PDA. Le PDA est associ un certain point daccs.
- RAMPE.msg: incluant les diffrents messages changs
- RAMPE.cpp: simulant le fonctionnement de RAMPE/INFOMOVILLE
- RAMPE.h: liste les diffrentes classes et attributs utiliss dans RAMPE.cpp
- omnetpp.ini: initialise quelques variables et paramtres
Deux modes sont utiliss pour la saisie des diffrents paramtres de la simulation (dont
le nombre de bornes par exemple, le nombre de PDAs, ) :
- Le mode intractif : dans ce mode, lutilisateur entre de faon interactive le nombre de

bornes et de PDAs dsirs pour la simulation.
- Le scnario prdfini dans un fichier XML : le nombre de bornes et de PDAs est prcis
dans un fichier XML. La structure dun fichier XML ressemble celle dun fichier
HTML avec une diffrence majeure : HTML reprsente les donnes tandis que XML
dcrit leur structure. Aussi HTML contient des balises et des tiquettes prdfinies
tandis que dans XML, elles sont dfinies par le programmeur selon son besoin. Un
fichier XML nest suppos valide que sil est conforme un fichier DTD (pour
Document Type Definition) ou XSD (pour XML Schema Definition), etc, fichiers qui
dcrivent les diffrents blocs et la structure dun fichier XML.
Figure 10- Les composants de RAMPE/INFOMOVILLE dans un fichier NED

dOMNeT++

Universit Paris-Est
A linitialisation, lapplication RAMPE/INFOMOVILLE est active (le module

interface reprsentant ltat de lapplication qui tourne sur le PDA est de couleur rouge).
Dans RAMPE/INFOMOVILLE, chaque borne installe dans une station de bus envoie des
trames balises ; linterface homme-machine utilisant une synthse vocale notifie le composant
blind de la prsence des stations sa proximit et fournit leurs noms et directions. Pour se
connecter une station dsire, le composant blind acquitte par les boutons de son PDA ;
Aprs acquittement, une requte dassociation est envoye depuis la borne vers la station
choisie et le PDA reoit alors une adresse IP.
Dans la simulation de la figure 10, un message est affich sur lcran du PC o tourne la
simulation, permettant la saisie interactive du choix de lutilisateur : sil choisit
Acknowledgment (le bouton Acknowledgment devient rouge) et le PDA sassocie la borne. Le
composant blind peut acquitter de nouveau pour demander quun carillon soit mis depuis la
borne afin de reprer sa position (llment borne devient rouge) ; la borne communique ensuite
avec le serveur ( Server sur la figure 10) de base de donnes, rcupre les informations lies
au transport de la station correspondante et les envoie au PDA. Linterface informe le composant
blind que la base de donnes a t bien tlcharge (ces messages vocaux sont montrs par
des popup messages visualiss au cours de la simulation). Si le composant blind acquitte,
il passe au niveau 1 qui nonce les lignes principales passant la station ; sil nacquitte pas,
linterface redonne linformation que la base de donnes a t bien tlcharge et quil est
possible dy naviguer. Du niveau 1, le blind peut passer au niveau 2 (nonciation des stations
squelettes) en acquittant, puis au niveau 3 (nonciation des stations disponibles depuis la station
squelette)
A tout moment de la simulation, si le blind appuie sur le bouton stop , lapplication

RAMPE/INFOMOVILLE se termine (linterface steint) sauf en cas dnonciation dun
message urgent o tous les boutons se transforment en boutons ACK ; ce message urgent est
envoy depuis le serveur de base de donnes vers la borne qui lenvoie son tour au PDA. Le
blind acquitte le message urgent, la base de donnes est actualise, retlcharge sur le PDA
et tout le processus recommence.
Cette simulation permet dillustrer de manire graphique le principe de fonctionnement

de lapplication. Elle peut aider un ergonome ajuster certaines spcifications. Elle pourrait tre
associe une synthse vocale et une manette de commandes simulant les touches du PDA
pour permettre une personne aveugle dapprendre le fonctionnement du systme.
1.5 Limitations du systme RAMPE test Lyon

notamment en ce qui concerne dune part les protocoles et la fiabilit de la transmission de
donnes de communication entre les bornes et les PDA et dautre part la capacit localiser et
guider lutilisateur de manire robuste. On peut rsumer ces limitations de la manire suivante :
Aspect rseau
Les deux lments principaux de RAMPE/INFOMOVILLE sont une borne installe dans
la station de bus et un dispositif de type PDA (et maintenant smartphone pour INFOMOVILLE)
port par la personne aveugle. Ces deux lments communiquent travers une liaison radio

Universit Paris-Est
WiFi. La technologie WIFI, bien quelle soit disponible et largement implmente, est toutefois
sujette aux erreurs et affecte par divers facteurs. Elle peut donc manquer de la fiabilit requise
pour des systmes comme RAMPE/INFOMOVILLE. Dautre part, les messages urgents
envoys depuis la borne vers les PDA qui y sont associs sont diffuss en utilisant le protocole
UDP en mode broadcast ; ce protocole est un protocole de la couche transport du modle OSI
non orient connexion et donc nest pas fiable: aucun acquittement nest requis de la part du
rcepteur et aussi les collisions ne sont pas dtectes sur une connexion sans fil comme cest le
cas pour les rseaux filaires, et donc les paquets perdus suite une collision ne sont pas
retransmis. Dautre part, le protocole TCP orient connexion de la couche de transport ne peut
pas tre utilis en mode broadcast : la connexion peut souffrir d'un dlai et dune congestion
intolrables cause des acquittements.
Le travail de cette thse a permis de proposer un nouveau protocole de communication
qui, dune part, fiabilise la communication radio et dautre part, du point de vue ergonomique,
founit aux utilisateurs du systme un indicateur de qualit de la liaison. Supposons qu'un
message urgent arrive un point d'arrt (dlai, accident, arrive de bus...). Toutes les personnes
prsentes larrt doivent tre averties. Le protocole propos essaye de garantir la rception des
messages urgents par les PDAs ; de plus, en utilisant comme mtrique le taux de pertes paquets
(en anglais PER pour Packet Error Rate), et en donnant au PDA la possibilit de calculer ce
taux, le protocole servira comme indicateur de qualit de la liaison sans fil.
Aspect localisation et guidage
La version actuelle de RAMPE/INFOMOVILLE ne propose pas rellement de service de

localisation et de guidage lexception dun guidage sonore lapproche des bornes. Cependant
plusieurs utilisations de la localisation et ventuellement du guidage sont envisageables dans
RAMPE/INFOMOVILLE : permettre une PAM de localiser une borne, permettre la borne de
localiser une PAM et de lorienter vers sa destination travers des chemins daccs faciles,
permettre une personne assistante prsente dans lenvironnement de la station du transport
public de localiser la PAM afin daller sa recherche et lassister dans son voyage,
Linfrastrucuture WiFi mise en place pour les besoins de communication entre les acteurs de
RAMPE/INFOMOVILLE peut aussi tre utilise pour des applications de localisation. Dans le
cadre de cette thse on sest a propos une solution base sur les ondes radio WiFi qui pourra
tre utilise pour la localisation des PAM et leur guidage dans RAMPE/INFOMOVILLE. Ce
service devrait pouvoir offfrir aux utilisateurs de lapplication une assistance supplmentaire
favorisant leur mobilit dans tous les types de transport public et les ples dchanges en
environnement intrieur ou extrieur.
1.6 Proposition damlioration du guidage auditif par le

carillon des bornes
Mme si on nintgre pas de technologie de localisation dans le systme, on pourrait
amliorer le guidage auditif par le carillon des bornes. Dans ce paragraphe, on propose des
solutions concernant le reprage spatial des bornes partir des carillons situs aux arrts ; ces
arrts peuvent tre proximit lun de lautre, leurs carillons peuvent interfrer et perturber les
PAM cherchant localiser lun dentre eux.
Aprs lassociation du PDA au point daccs, la borne installe larrt de bus

commence automatiquement sonner. Si deux bornes (donc deux arrts de bus) proximit

Universit Paris-Est
lune de lautre se mettent sonner en mme temps suite la requte de deux utilisateurs
aveugles, un aveugle cherchant localiser la premire station pourrait se mettre suivre le
carillon sonnerie de la station voisine.
Pour amliorer cette situation, on propose que les sonneries de deux bornes voisines soient
diffrentes lune de lautre. Ds que la PAM sassocie avec une borne et avant quelle ne
commence sonner, celle-ci enverra le modle de carillon dans un message spcifiquement
destin laveugle et quil peut entendre sur son PDA. Ds que lutilisateur aura bien entendu la
sonnerie, il demandera alors la borne de sonner afin de reprer sa position.
Dans le cas o plus de deux stations sont proximit lune de lautre, les bornes peuvent sonner
ensemble suite la demande de plusieurs PAM. Mme si les sonneries sont diffrentes et mme
si un modle de la sonnerie est envoy sparment chaque PAM, lutilisateur risque davoir du
mal se reprer au milieu de ces diffrents carillons et de ce fait avoir des difficults
sorienter vers larrt de bus choisi.
On peut imaginer un protocole de communication entre les diffrentes bornes prsentes dans un
mme site dune faon viter que plusieurs ou toutes les bornes sonnent en mme temps.
On peut imaginer un systme de jeton qui circulera entre les bornes. Celle qui le saisit a le droit
de sonner pour un certain temps avant de librer le jeton pour la borne suivante. De cette faon
les bornes sonneront lune la suite de lautre. Un dlai de quelques secondes pourra tre fix
entre les sonneries des diffrentes bornes dune faon minimiser le conflit des sons. Ce dlai
doit cependant tre acceptable pour la PAM.

Universit Paris-Est
Chapitre 2- Technologies sans fil de communication et de localisation
Chapitre 2
Technologies sans fil de communication et de localisation
2.1 Motivations
Dans le but de dvelopper des systmes de transmissions de donnes assurant une
communication indpendante de lemplacement des priphriques informatiques qui composent
le rseau, et utilisant les ondes radio lectromagntiques plutt quune infrastructure cble,
plusieurs technologies sans fil ont t mises en place. Ces technologies diffrent par le dbit
offert, la porte, la consommation en nergie des dispositifs, la disponibilit dans les
priphriques informatiques, etc.
RAMPE/INFOMOVILLE est un systme daide aux personnes aveugles reposant sur

une technologie de communication courte distance. Trois points importants sont considrer
dans le choix de cette technologie: sa disponibilit dans les dispositifs mobiles et sa facilit
dimplmentation, la fiabilit ou en dentre termes les performances offertes ainsi que le dbit et
la porte permis, et la possibilit dutilisation de cette technologie dans des ventuelles
extensions et amliorations pouvant tre apportes au systme. Lune des applications possibles
de cette technologie de communication sans fil, qui savre tre intressante pour le systme
RAMPE/INFOMOVILLE, est son utilisation dans des services de localisation. Plusieurs
systmes de golocalisation/localisation dobjets mobiles ont t dvelopps et quelques uns
implments; certains fonctionnent dans les zones intrieures aux btiments, dautres en
extrieur, certains ncessitent des quipements supplmentaires, dautres peuvent se baser sur
les infrastructures de communication existantes.
On compare dans les paragraphes qui suivent de ce chapitre les trois technologies sans fil
Zigbee, Bluetooth et Wifi. On explique leur architecture et fonctionnement pour passer ensuite,
dans la deuxime partie du chapitre, un tat de lart sur les systmes, mthodes et techniques
de localisation existants. Les trois aspects de choix de la technologie sans fil WiFi pour
lapplication RAMPE/INFOMOVILLE (disponibilit, fiabilit et utilisation en dehors de la
communication) sont alors dtaills et ce choix justifi.
2.2 Technologies de communication sans fil courte distance

Commenons par un tableau comparatif des trois technologies Zigbee, Bluetooth and
WiFi:
Protocole Zigbee Bluetooth Wi-Fi

Standard IEEE 802.15.4 802.15.1 802.11a/b/g/n/n-draft
Autonomie avec pile Annes Jours Heures
Nombre de nuds >65000 7 (non spcifi par la
norme et dpend du
dbit offrir pour
une station) mobile)

Universit Paris-Est
Dbits offerts 20- 250 Kb/s 1 Mb/s 11-54-108-320 Mb/s

Porte 100 mtres 10-100 mtres 300 mtres
Applications Surveillance et Remplacement de Internet (web et
Contrle cbles messagerie
lectronique ou e-
mail), Vido,
rseaux de donnes
Disponibilit Capteurs Ordinateurs Ordinateurs
portables, PDA, portables, PDA,
Tlphones mobiles Tlphones mobiles
Table 1- Technologies de communication sans fil
2.2.1 Zigbee
2.2.1.1 Norme IEEE 802.15.4
ZigBee est bas sur le standard IEEE 802.15.4 qui est un protocole de communication
utilis par exemple dans les rseaux sans fil personnels (ou en anglais LR-WPAN pour Low
Rate Wireless Personal Area Network ou aussi LP- WPAN pour Low Power Wireless Personal
Area Network) du fait de leur faible consommation, de leur faible porte et du faible dbit de
leurs dispositifs [125]. Cette technologie a pour objectif doffrir une solution simple, peu
coteuse, dont la partie radio a une consommation rduite et des capacits dauto-organisation.
Zigbee est apparu aprs les technologies Bluetooth et WiFi pour assurer des applications
qui ntaient pas faisables avec ces deux technologies ; ses spcifications, disponibles au sein de
la communaut industrielle "ZigBee Alliance", ont t ratifies le 14 dcembre 2004 et en 2005
la communaut a publi les premires spcifications officielles de la version ZigBee 1.0. Cette
version propose un protocole de dbit et de porte relativement faibles mais dont la fiabilit est
leve et la consommation rduite (les nuds sont conus pour fonctionner plusieurs mois
(jusqu deux ans) en autonomie complte). On trouve ZigBee dans les contrles industriels, les
applications mdicales, les dtecteurs de fume et dintrusion.
2.2.1.2 ZigBee et les couches IEEE
Ce protocole fonctionne, comme WiFi, dans les couches basses du modle IEEE : la
couche Physique (couche radio note PHY) et la couche Liaison de Donnes (note MAC pour
Medium Access Control). Les couches suprieures sont dfinies par ZigBee alliance [125].
Couche Physique
Elle est gre au niveau matriel. C'est elle qui s'occupe de l'mission et de la rception
des ondes radio. Elle dfinit les caractristiques telles que la bande de frquence et l'arrangement
des canaux, les caractristiques de lmetteur, de la modulation, du rcepteur, etc. Zigbee
fonctionne dans les bandes de frquence 2.4002.484 GHz (16 canaux), 902-928 MHz (10
canaux) and 868.0868.6 MHz (1 canal) en Europe. La couche physique utilise la modulation de
squence directe talement de spectre (DSSS- Direct Sequence Spread Spectrum).

Universit Paris-Est
Couche Liaison de Donnes
Deux types de dispositifs Zigbee ont t dfinis:
- Le dispositif ayant toutes les fonctions possibles FFD- Full Function Device : il peut tre
un coordinateur, un routeur, un dispositif reli un capteur.
- Le dispositif ayant des fonctions limites RFD- Reduced Function Device : il fonctionne
uniquement en dispositif.
Pour former un rseau Zigbee, au moins un FFD doit tre prsent et communique sur le mme
canal physique avec des RFD. Le FFD peut dialoguer avec des RFD et des FFD, tandis que le
RFD dialogue avec un FFD uniquement.
La couche Liaison de Donnes peut fonctionner selon deux modes: le premier dit
Rseau avec envoi de balise (en anglais beacon), le second dit Rseau sans envoi de
balise (non-beacon).
Rseau avec balise
Dans ce type de rseau le coordinateur, qui est responsable du routage travers le

rseau, met priodiquement une trame balise afin que lensemble des dispositifs relis soient
synchroniss [126]. Lors de la rception d'une trame balise, tous les dispositifs sont informs de
la dure de la super-trame (priode d'activit du coordinateur et qui mesure 16 intervalles
temporels ou time-slots) et quel moment ils pourront transmettre des donnes. Ils recevront
aussi une indication quand le coordinateur entrera en hibernation et pour quelle dure. Les
dispositifs savent alors quand ils peuvent rentrer en hibernation ou transmettre. La dure de la
super-trame et la priode d'envoi de la balise varient entre 15.38ms et 252s. Tous les dispositifs
doivent se rveiller quelques instants avant l'mission de la balise et restent en attente de cette
trame pour se synchroniser.
Il existe deux types daccs au medium:
- CAP (Contention Access Period): tous les dispositifs peuvent transmettre dune faon
alatoire, mais en respectant la dure d'un slot (une transmission ne peut pas dmarrer au milieu
d'un slot).
- CFP (Contention Free Period): permet de garantir l'accs au canal un dispositif pendant une
dure dtermine en nombre de slots, appele GTS (Guaranteed Time Slot). L'allocation d'un
GTS fait suite une demande de la part d'un dispositif pendant la CAP. L'information sur la
rservation d'un GTS (et l'affectation du GTS dans la CFP) est inscrite dans la prochaine balise,
avec l'adresse du dispositif concern, la dure du GTS et le slot de dpart. La libration d'un
GTS se fait soit par demande de la part du dispositif, soit parce que le coordinateur n'arrive plus
joindre le dispositif.
Tous les dispositifs voulant communiquer pendant la CAP entre deux balises sont mis en
concurrence avec les autres en utilisant le protocole CSMA/CA.

Universit Paris-Est
Rseau sans balise
Dans ce mode, le coordinateur nmet pas de trame balise et reste par dfaut dans l'tat
d'attente de donnes. Le dispositif qui veut transmettre regarde si le canal est libre. Si c'est le
cas, alors il transmet sinon il attend une priode alatoire (dfini dans le protocole IEEE
802.15.4-2003) [126].
Lorsque le coordinateur a des donnes transmettre un dispositif, il attend que le
dispositif rentre en contact et lui demande les donnes. Le coordinateur envoie alors un accus
de rception de la requte. Si des donnes sont en attente, le coordinateur transmet les donnes
en utilisant le mme principe (CSMA/CA). S'il n'y a pas de donnes en attente, le coordinateur
envoie une trame de donnes vide (longueur 0). Le dispositif accuse la rception des donnes.
Cette solution peut permettre daugmenter lautonomie des batteries des capteurs et
dutiliser le canal uniquement lorsquil est ncessaire de transmettre des donnes. Par contre du
fait de CSMA/CA, laccs au canal nest pas garanti dans une priode donne ; il dpendra de la
densit du rseau et du nombre de dispositifs voulant transmettre simultanment.
Couche rseau et application
Les couches suprieures, rseau (NWK pour Network) et application (APL) sont dfinies
par la ZigBee Alliance. La couche rseau introduit un composant ZigBee supplmentaire :
le ZigBee Router (ZR), qui en plus dtre un composant FFD a la responsabilit de grer les
adresses locales et de maintenir des tables de routage. Le rseau ZigBee permet diffrent type de
topologie : en toile, maill (mesh) ou arborescent.
La table de dcouverte d'une route contient les informations sur les sources du message.
Elle stocke l'adresse d'origine du dispositif qui a fait la demande et l'adresse du dispositif qui va
transmettre les donnes en tant qu'intermdiaire (entre la source et la destination). Elle contient
aussi les cots de transmission entre la source jusqu'au nud actuel et du nud jusqu'au
destinataire. Elle peut donc adapter la route pour tre plus performante en mettant jour les
adresses utiliser.
2.2.2 Bluetooth
2.2.2.1 Norme IEEE 802.15.1
Bluetooth est bas sur le standard IEEE 802.15.1. Cest une technologie radio courte
distance destine simplifier les connexions entre les appareils lectroniques. Elle a t conue
dans le but de remplacer les cbles entre les ordinateurs et les imprimantes, les scanners, les
claviers, les souris, les tlphones portables, les PDA, les autoradios et les appareils photo
numriques.
Les spcifications de Bluetooth sont disponibles au sein de la communaut Bluetooth

Special Interest Group (SIG) qui a annonc plusieurs versions et plusieurs normes de cette
technologie:
- IEEE 802.15.1- 2002 (Bluetooth 1.1) : premire version de Bluetooth assurant un dbit de
1Mb/s. Cependant, cette version avait beaucoup de problmes surtout en ce qui concerne
lintroprabilit des quipements.
- IEEE 802.15.1- 2005 (Bluetooth 1.2) : propose des amliorations par rapport la version
prcdente surtout en ce qui concerne la rapidit de connexion entre les quipements.

Universit Paris-Est
- Bluetooth 2.0 : propose des dbits 3 fois plus importants que les versions prcdentes, de
lordre de 3Mb/s thorique.
- Bluetooth 2.1 : apportant des modifications la version 2.1 notamment au niveau scurit.
- Bluetooth 3.0 : Annonc en avril 2009 rutilise la couche air 802.11 pour atteindre des dbits
sur linterface air de 54 Mbits/s et de 24 Mbit/s au niveau applicatif dans les bandes 2.5 et 5
GHz.
La topologie des rseaux Bluetooth a comme brique de base le Piconet. Un Piconet

forme un rseau sans fil personnel (WPAN) de type ad-hoc, et suit une topologie en toile: 1
matre et plusieurs esclaves. Le matre peut administrer jusqu' 7 esclaves et 255 dispositifs en
mode inactif (ou parked). La communication est directe entre le matre et un esclave. Les
esclaves ne peuvent pas communiquer entre eux et sont synchroniss sur l'horloge et la
frquence du matre (cest lui qui dtermine la squence de saut de frquence pour tout le
Piconet). Les priphriques esclaves peuvent avoir plusieurs matres, les diffrents Piconets
peuvent donc tre relis entre eux. Le rseau ainsi form est appel un Scatternet. Un
dispositif peut jouer le rle dun pont (ou bridge) tout en tant un Matre dans un piconet et un
esclave dans un autre.
Piconet
Piconet
Esclave
Esclave Esclave
Esclave
Esclave
Matre Matre
Esclave Esclave
Esclave
Matre
Esclave
Piconet
Figure 11- Rseau Scatternet Bluetooth
2.2.2.2 Bluetooth et les couches IEEE
Comme Zigbee, la technologie Bluetooth repose sur les deux couches basses du modle
IEEE, la couche PHY et la couche MAC.
Couche Physique
Elle utilise l'une des bandes de frquences ISM (Industrial, Scientific & Medical)
rserve pour l'Industrie, la Science et la Mdecine. La bande de frquences utilise est
disponible au niveau mondial et s'tend sur 83,5 MHz (de 2,4 2,4835 GHz). Cette bande est

Universit Paris-Est
divise en 79 canaux spars de 1 MHz. Le codage de l'information se fait par sauts de

frquence (FHSS- Frequency Hopping Spread Spectrum).
Il existe trois classes de modules radio Bluetooth sur le march ayant des puissances
diffrentes et donc des portes diffrentes:
Classe Puissance Porte

1 100 mW (20 dBm) 100 mtres
2 2,5 mW (4 dBm) 10 mtres
3 1 mW (0 dBm) 1 mtre
Table 2- Les trois classes de modules radio Bluetooth
La plupart des fabricants d'appareils lectroniques utilisent des modules de classe 2.
Couche MAC
Chaque dispositif a une adresse physique quivalente l'adresse MAC d'une carte rseau
et nomme BD_ADDR- Bluetooth Device Address. Cette adresse est code sur 48 bits. La
technologie Bluetooth permet la transmission de deux types de trafic et de donnes: un trafic
ayant des contraintes temps rel comme la voix et laudio, et un trafic nayant pas des
contraintes de temps. Dans ce but, deux types de liaisons sont dfinis entre 2 dispositifs:
- Synchronous Connection Oriented- SCO pour la voix et laudio.

- Asynchronous Connectionless Links- ACL pour la transmission des donnes.
Les paquets ACL contiennent 72 bits nomms Access Code, 54 bits dentte et 16 bits de CRC
en plus des donnes utiles. Diffrents types de paquets existent pour diffrentes longeurs de
donnes transmettre. Le paquet ayant le plus long payload est nomm DH5. Il peut transmettre
339 octets, soit 2,712 bits. Les liens SCO fonctionnent un dbit de 64 kb/s, et il est possible
davoir trois liens en full-duplex simultanment pour la voix ou aussi un mixage de voix et de
donnes.
2.2.3 Wi-Fi (Wireless Fidelity)

Le rseau local sans fil (not WLAN pour Wireless Local Area Network) est un
rseau assurant un ensemble de dispositifs mobiles (ordinateurs portables,
ordinateurs de poche de type PDA, etc), un lien avec le rseau cbl existant,
utilisant les ondes radios plutt quune liaison filaire, et offrant aux utilisateurs de
ces dispositifs un accs lensemble des ressources et des services du rseau de
lentreprise.
LIEEE- Institute of Electrical and Electronics Engineers a initi la spcification 802.11,

norme rgissant les rseaux locaux sans fil, en 1990 et lavait finalise en 1997. Le nom WiFi
(pour Wireless Fidelity parfois not Wi-Fi), correspond initialement au nom donn la
certification dlivre par la WECA (Wireless Ethernet Compatibility Alliance), l'organisme
charg de maintenir l'interoprabilit entre les matriels rpondant la norme 802.11. Les
rseaux sans fil deviennent de plus en plus rpandus dans les zones forte concentration
d'utilisateurs (gares, aroports, hotels, trains,...), afin de leur fournir, en gnral, un accs au
rseau Internet ; ces zones sont appeles "Hot Spots".

Universit Paris-Est
Un autre standard de rseau sans fil a t propos par l'ETSI (European

Telecommunications Standards Institute) en 1996 : HiperLAN (pour HIgh PERformance radio
LAN). Cependant, cette technologie na pas connue de dveloppement industriel et seule la
technologie Wi-Fi est reste.
Dans le cadre de cette thse, nous nous intresserons plus particulirement la

technologie WiFi dont les principes en sont prsents dans les paragraphes suivants.
2.2.3.1 Norme IEEE 802.11
La norme IEEE 802.11 est en ralit la norme initiale offrant des dbits de 1 ou 2 Mb/s.
Des rvisions ont t apportes la norme originale afin d'optimiser le dbit ou bien prciser des
lments afin d'assurer une meilleure scurit ou une meilleure interoprabilit. Le tableau 3
prsente les diffrentes rvisions de la norme 802.11 et leurs significations:
Nom de la norme Nom Description

Legacy ou IEEE802.11- Propose des dbits de 1 ou 2 Mbps envoys dans des signaux
802.11 1997 ou IEEE802.11- infrarouges et utilise la modulation DSSS (Direct Sequence Spread
1999 Spectrum)
Propose un dbit de 11 Mb/s avec une porte pouvant aller jusqu'
300 mtres dans un environnement dgag. La plage de frquence
802.11b WiFi
utilise est la bande des 2.4 GHz. 802.11b avec la norme 802.11g
sont les plus rpandues aujourdhui
Offre un dbit de 54 Mb/s sur la bande de frquence des 2.4 GHz.
Elle est compatible avec la norme 802.11b, ce qui signifie que des
802.11g WiFi
matriels conformes la norme 802.11g pourront fonctionner en
802.11b.
Permet d'obtenir un haut dbit (54 Mb/s). La norme 802.11a spcifie
802.11a WiFi5
8 canaux radio dans la bande de frquence des 5 GHz.
Vise amliorer la qualit de service au niveau de la couche liaison
de donnes. Elle dispose d'un systme de priorit spcifiant le
Amlioration de la traitement de l'information en fonction de sa nature. Intitule
802.11e
qualit de service Wireless Multimedia Extension (WME), elle libre en priorit de la
bande passante pour le transport de la voix ou de la vido, que pour
les donnes brutes.
Concerne l'itinrance entre les points d'accs permettant un
802.11f Itinrance (roaming) utilisateur de changer de point d'accs d'une faon transparente lors
d'un dplacement
Son but est d'amliorer la scurit des transmissions (gestion et
distribution des cls, chiffrement et authentification) dans les
transmissions utilisant les technologies 802.11a, 802.11b et 802.11g.
Il dfinit un rseau de scurit robuste (Robust Security Network ou
RSN) comportant des amliorations par rapport au mode de
scurisation WEP (Wired Equivalent Privacy). Elle utilise les
802.11i WPA2
moyens d'authentification et de cryptage suivants : IEEE 802.1x, Le
processus de chiffrement bas sur l'algorithme AES (Advanced
Encryption Standard) et le processus de chiffrement TKIP (Temporal
Key Integrity Protocol) permettant d'obtenir le mode de scurisation
WPA (moins robuste que WPA2) l'aide de cls de 128 bits
dynamiques modifies de manire alatoire.
Encore ltat de projet, il permet d'atteindre un dbit allant jusqu'
802.11n TGn ou P802.11n 270 Mbits/s ou 300 Mbits/s respectivement dans la bande de
frquences des 2,4 GHz ou 5 GHz, grce la technologie MIMO

Universit Paris-Est
(Multiple-Input Multiple-Output) (qui permet d'utiliser, la fois,

plusieurs missions spatiales et plusieurs antennes pour les
rcepteurs et metteurs), le regroupement des canaux radio
permettant d'augmenter la bande passante et l'agrgation de paquets
de donnes qui permet l'augmentation des dbits. 802.11n combine
jusqu' 8 canaux non superposs.
Rcemment, le Draft 8.0 fut lanc en Mars 2009 et le draft 9.0
suivra.
Table 3- Les diffrentes normes WiFi
2.2.3.2 WiFi et les couches OSI- Couche Physique
Comme tous les standards IEEE 802, le standard 802.11 se concentre sur les deux
couches infrieures du modle IEEE, la couche PHY et la couche MAC:
Figure 12- Les deux couches de 802.11
Normes 802.11b et 802.11g [15, 167]

Ce sont les deux normes les plus utilises de nos jours. Toutes les deux fonctionnent
dans la bande de frquence 2.400-2.4835 Ghz, dont lutilisation ne ncessite pas lobtention
dune licence. Cette bande de frquence est utilise dans les zones intrieures et extrieures, a
une largeur de 83.5 MHz et elle est dcoupe en 14 canaux spars de 5 MHz, sauf pour le canal
14 qui est espac de 12 Mhz du canal 13. Les 11 premiers canaux sont utiliss aux Etats-Unis,
les 13 premiers en Europe et les 14 canaux au Japon.
Canal 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Frquence
2.412 2.417 2.422 2.427 2.432 2.437 2.442 2.447 2.452 2.457 2.462 2.467 2.472 2.484
(GHz)
Table 4- Dcoupage de la bande dans 802.11b/g
Ainsi les canaux adjacents se recouvrent partiellement ; les canaux spars de 20Mhz (1 et 5, 4
et 8 par exemple) sont isols et donc ninterfrent pas.
La norme 802.11b utilise les modulations CCK (Complementary Code Keying) et ltalement du
spectre par squence directe (DSSS pour Direct Sequence Spread Spectrum) [15]. La norme

Universit Paris-Est
802.11g utilise la modulation OFDM (Orthogonal Frequency Division Multiplexing) pour les
dbits de 6 54 Mbps et les modulations CCK, DSSS et BPSK/QPSK (Binary and Quadrature
Phase-shift Keying) pour les dbits infrieurs 6 Mbps.
La puissance maximale de sortie premise aux USA est de 1000mW tandis qu'en Europe elle est
de 100mW.
Norme 802.11a [168]

802.11a fonctionne dans la bande des 5GHz, nomme "La Bande Universelle de
l'Infrastructure des Rseaux et de l'Information" (UNII- Universal Networking Information
Infrastructure band) et divise en 3 parties: UNII-1 est pour l'utilisation en zone intrieure
uniquement, UNII-2 est pour l'utilisation en zone intrieure et extrieure et UNII-3 est utilise
uniquement pour le bridging en zone extrieure uniquement. Cette bande de frquence a t
dcoupe en 18 canaux spars de 20Mhz. 11 canaux sont utiliss pour les zones intrieurs avec
une puissance maximale mise de 200mW ce qui permet de dfinir 8 canaux distincts d'une
largeur de 20 Mhz chacun, c'est--dire une bande suffisamment large pour ne pas avoir de
parasitage entre canaux en zone intrieure, et 7 canaux sont utiliss pour les zones extrieures
avec une puissance maximale mise de 1000mW. 802.11a utilise uniquement la modulation
OFDM- Orthogonal Frequency Division Multiplexing.
Voici les frquences associes aux 11 canaux pour les zones intrieures:
Canal 36 40 42 44 48 50 52 56 58 60 64
Frquence
5.180 5.200 5.210 5.220 5.240 5.250 5.260 5.280 5.290 5.300 5.320
(GHz)
Table 5- Dcoupage de la bande dans 802.11a (zone intrieure)
Et les frquences associes aux 7 canaux pour les zones extrieures:
Canal 149 152 153 157 160 161 165

Frquence
5.745 5.760 5.765 5.785 5.800 5.805 5.825
(GHz)
Table 6- Dcoupage de la bande dans 802.11a (zone extrieure)
2.2.3.3 Les modes dopration de 802.11
Le standard 802.11 dfinit deux modes dopration: le mode Infrastructure et le mode

Ad-Hoc.
2.2.3.3.1 Mode Infrastructure
En mode infrastructure, le rseau sans fil consiste au minimum en un point daccs (AP-
Access Point) connect ventuellement linfrastructure du rseau filaire et un ensemble de
postes rseaux sans fil, appeles stations. L'ensemble form par le point d'accs et les stations
situes dans sa zone de couverture est appel ensemble de services de base BSS- Basic Service
Set et constitue une cellule. Chaque BSS est identifi par un BSSID- Basic Service Set
Identifier, un identifiant de 6 octets (48 bits). Dans le mode infrastructure, le BSSID correspond
l'adresse MAC- Medium Access Control du point d'accs. De mme, la zone de service

Universit Paris-Est
correspondante une cellule ou encore un AP est identifie par un SSID- Service Set
Identifier, un identifiant de 32 caractres au format ASCII.
Un ensemble de services tendu ou ESS- Extended Service Set est un ensemble dau moins deux
BSS formant un seul sous-rseau, et relis entre eux par une liaison appele systme de
distribution (DS- Distribution System) (cf. figure 13). Le DS peut tre aussi bien un rseau
filaire, qu'un cble entre deux points d'accs ou bien mme un rseau sans fil.
Un ESS est repr par un ESSID- Extended Service Set Identifier, un identifiant de 32 caractres
au format ASCII, et qui reprsente le nom de tout le rseau en infrastructure, donc le SSID
commun tous les BSS. En dautres termes, lESS est un ensemble de plusieurs APs ayant le
mme SSID.
Figure 13- Mode Infrastructure de 802.11
Pour quune station mobile puisse mettre et recevoir des donnes au sein dun BSS
(communiquer avec dautres stations du rseau filaire ou du rseau sans fil), elle doit se
connecter au rseau 802.11 en sassociant un point daccs et ventuellement en
sauthentifiant.
Scanning
La couche MAC 802.11 est responsable de la manire dont un client sassocie un point
daccs. Lorsquun client 802.11 entre dans le rayon daction dun ou plusieurs points daccs
(soit aprs un allumage, aprs un mode veille ou simplement en entrant gographiquement dans
la cellule), il a besoin dinformations de synchronisation de la part du point daccs pour sy
associer: ces informations sont obtenues par le Scanning. Deux modes de Scanning existent
[15] :
Passive Scanning : Dans ce mode, la station attend les informations de synchronisation

contenues dans les trames balises (beacon frames) envoyes priodiquement par lAP. En effet
chaque point d'accs diffuse rgulirement une trame balise donnant des informations sur son
BSSID, ses caractristiques et ventuellement son SSID (cf. paragraphe 2.2.3.3.1). Pour pouvoir

Universit Paris-Est
sassocier (cest--dire se connecter un rseau WiFi et pouvoir mettre et recevoir des trames)
un WLAN particulier, une station doit avoir le mme SSID que le point d'accs.
Active Scanning : dans ce mode, la station essaye de trouver un AP en envoyant des

requtes (Probe Request) et en attendant des rponses (Probe Response) du point daccs.
Quand une station mobile rentre dans la zone de couverture d'un point d'accs, elle diffuse sur
chaque canal une requte contenant le SSID pour lequel elle est configure ainsi que les dbits
quelle supporte. Si un point d'accs configur avec ce SSID est prsent il renvoie une rponse
contenant ses caractristiques de transmission (dbits supports ).
Modles de slection du point daccs
La norme qui ne porte que sur la couche PHY et la couche MAC, ne spcifie pas de
stratgie de slection des points daccs par une station. Il est possible de dterminer des critres
(RSB, charge rseau) et une heuristique permettant doptimiser la bande passante et la
disponibilit dun rseau WiFi [17, 18]. Parmi ces approches, on distingue deux catgories :
- RSB qui consiste choisir lAP permettant le meilleur RSB indpendamment de la

charge ou du nombre d'utilisateurs.
- Equilibre de charge qui consiste considrer la fois le RSB et la charge de lAP et

choisir lAP qui semble offrir la meilleure largeur de bande disponible.
Authentification
Un des problmes majeurs des rseaux sans fils est la scurit, notamment la
confidentialit
et la vulnrabilit du rseau qui peut tre victime dune coute ou dune intrusion. Les
mcanismes dauthentification prvues dans la norme cherchent pallier cette faiblesse de
fonctionnement du
point de vue scurit. La norme prvoit deux mcanismes de base :
Open System Authentication: qui est simplement un mcanisme qui sert identifier la
station mobile au point daccs, et qui rsulte gnralement en une rponse positive.
Shared Key Authentication: qui utilise un algorithme de cryptage des donnes:

lalgorithme WEP- Wired Equivalent Privacy avec une cl secrtre de cryptage de 40 bits ou de
104 bits. Cet algorithme, peu robuste, a t par la suite amlior par lalgorithme WPA (Wi-Fi
Protected Access) qui gnre rgulirement de nouvelles cls dynamiques - pour chaque paquet
de 10 Koctets de donnes transmises sur le rseau. L'objectif de ce type dauthentification et de
cryptage est d'offrir une scurit quivalente celle offerte par un rseau filaire traditionnel.
L'authentification se fait en 4 tapes (4 messages sont changs pour permettre lAP de vrifier
que la station a la cl correcte):
1. Demande d'authentification de la part du poste sans fil vers lAP

2. Rponse de la part de lAP contenant un message alatoire de 128 octets
3. Deuxime message du poste sans fil contenant le message alatoire prcdent crypt par
l'algotithme WEP ou WPA

Universit Paris-Est
4. Vrification par lAP de l'intgrit de la trame reue et du message de 128 octets qu'elle
contient, et envoie dune rponse positive ou ngative selon le rsultat.
Aprs cette Authentification, commence lAssociation.
Association
Durant lassociation, la station mobile STA et lAP changent des informations
supplmentaires. La station obtiendra alors un identificateur dassociation (AID pour
Association Identifier). Cet AID est une valeur donne par lAP et qui reprsente l'identification
de 16 bits de la STA. La longueur de ce champ AID est de 2 octets. La station peut mettre et
recevoir des trames aprs que cette association soit termine avec succs.
Rsum des oprations effectues

Ces diffrents mcanismes sont illustrs par le schma ci-dessous :
AP1 AP2
1 1
2
4
2
5
6
STA
Figure 14 Oprations effectues dans 802.11 en mode infrastructure
1. STA envoie une probe request

2. AP rpond par une probe response. 1 et 2 reprsentent la variante du Active Scanning
3. La station aura une liste des APs du rseau et choisit alors le meilleur AP (en gnral
lAP avec le meilleur RSB)
4. La station sauthentifie au Point dAccs
5. La station envoie une requte dassociation
6. AP rpond par une rponse dassociation en attribuant un AID la station.
Les diffrentes trames de 802.11

Il y a trois types de trames changes dans un rseau WiFi 802.11 en mode infrastructure
[15] :
- Les trames de Donnes, utilises pour la transmission des donnes.
- Les trames de Contrle, utilises pour contrler laccs au support (eg. RTS, CTS, ACK).
- Les trames de Gestion, transmises de la mme faon que les trames de donnes pour lchange
dinformations de gestion, mais qui ne sont pas transmises aux couches suprieures.

Universit Paris-Est
2.2.3.3.2 Mode Ad-Hoc
Le mode Ad-Hoc, point point, ou ensemble de services de base indpendants (IBSS-

Independent Basic Service Set), reprsente simplement un ensemble de stations sans fil 802.11
qui communiquent directement entre elles sans point daccs ni connexion un rseau filaire.
Un IBSS est constitu dun seul BSS.
Figure 15- Mode Ad-Hoc de 802.11
2.2.3.4 La couche Liaison de Donnes
La norme 802.11 ne dfinit que la sous-couche MAC de la couche liaison de donne du

modle OSI. Elle utilise une adresse physique classique sur 48 bits. Elle sinterface avec la sous-
couche LLC 802.2, simplifiant ainsi le pontage entre les rseaux sans fil et les rseaux filaires.
La couche 802.11 MAC est trs proche de 802.3 MAC dans sa conception: plusieurs
utilisateurs peuvent exister sur un support partag en faisant dtecter ce support permettant un
accs multiple. Elle dfinit deux types de protocoles ou daccs:
- DCF- Distributed Coordination Function

- PCF- Point Coordination Function
2.2.3.4.1 DCF et le protocole CSMA/CA
Pour les LAN Ethernet 802.3, le protocole CSMA/CD (Carrier Sense Multiple Access
with Collision Detection) gre laccs des stations au bus ; il dtecte et gre galement les
collisions qui se produisent lorsque deux priphriques ou plus tentent de communiquer
simultanment. Pour dtecter ces collisions, une station doit tre capable de transmettre et
dcouter en mme temps. Or, dans les systmes radio, il ne peut y avoir transmission et coute
simultanes. Alors le standard 802.11 fait appel un protocole lgrement modifi, appel
CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance), ou la fonction DCF
(Distributed Coordination Function) qui dfinit un accs de type Contention . La priode
pendant laquelle ce protocole est utilis sappelle CP- Contention Period o chaque station
essaye de gagner laccs au medium. Le protocole CSMA/CA tente dviter les collisions en
imposant une coute du mdium avant une tentative de transmission ainsi quun acquittement

Universit Paris-Est
systmatique des paquets (ACK- Acknowledgment): si le paquet est intact la rception, la

station rceptrice met une trame ACK. Si la trame ACK nest pas dtecte par la station
mettrice (parce que le paquet original ou le paquet ACK na pas t reu intact), une collision
est suppose et le paquet de donnes est retransmis aprs attente dun autre temps alatoire.
Le protocole CSMA/CA fonctionne en se basant sur des temporisateurs. Une station qui
souhaite mettre coute le canal : si le medium est libre elle met et attend lacquittement et si le
medium est occup, elle attend un temps alatoire appel Back-off correspondant un certain
nombre de slots temporels puis tente de nouveau daccder au mdium.
Les deux sens de dialogue (AP STA et STA AP) se droulent sur la mme bande de
frquence, il est donc organis en half duplex. Chaque phase de dialogue est spare par un
espace entre trame (Frame Space) pendant lequel aucune transmission na lieu. Il existe trois
types despace entre trames:
- SIFS (Short Inter-Frame Space): le plus petit des IFS, Il est utilis entre les trames de la couche
MAC au sein d'un mme dialogue: donnes de la station mettrice et accus de rception de la
station rceptrice.
- PIFS (Point Coordination Function IFS): espace inter trame utilis pour les trames PCF (cf.
paragraphe suivant sur le PCF). Il permet un accs prioritaire de la station avec ce type de trames
sur les stations du rseau. Sa valeur correspond un SIFS plus un petit temps appel slot.
- DIFS (Distributed Coordination Function IFS) temporisateur inter trame pour l'accs distribu
utilis par les stations pour accder au support (en mode DCF).
Figure 16 Fonctionnement du CSMA/CA
Problme du "Terminal Cach"
Cest un autre problme de la couche MAC sans fil: deux stations situes de chaque ct
dun point daccs peuvent entendre toutes les deux une activit du point daccs, mais pas de
lautre station, ce problme gnralement li aux distances ou la prsence dun obstacle. Pour
rsoudre ce problme, le standard 802.11 dfinit sur la couche MAC un protocole optionnel de
type RTS/CTS (Request To Send/Clear To Send). Lorsque cette fonction est utilise, une station
mettrice transmet un RTS comprenant ladresse source, ladresse destination et la dure

Universit Paris-Est
ncessaire pour sa transaction (i.e. la dure de transmission du paquet et la rception de son

ACK), et attend que le point daccs rponde par un CTS comprenant les mme informations.
Toutes les stations du rseau peuvent entendre le point daccs, aussi les informations contenues
dans les RTS/CTS leur permettent de retarder toute transmission prvue, marquant un NAV
(Network Allocation Vector) qui comprend la dure ncessaire pour une transaction. La station
mettrice pouvant alors transmettre et recevoir son accus de rception sans aucun risque de
collision. Le protocole RTS/CTS rajoute de loverhead, il est gnralement rserv aux plus
gros parquets pour lesquels la probabilit de collision devient importante (cf. figure 17).
Figure 17 Protocole Request To Send/Clear To Send (RTS/CTS)
La couche MAC 802.11 offre aussi deux autres caractristiques de robustesse: le calcul
de contrle (CRC- Cyclic Redundancy Check) et la Fragmentation des paquets. Pour chaque
paquet, un CRC est calcul afin dassurer que les donnes nont pas t corrompues durant leur
transit. La Fragmentation quand elle permet de diviser les gros paquets en units de plus petite
taille, ce qui savre particulirement utile dans les environnements trs congestionns ou
lorsque les interfrences sont importantes.
2.2.3.4.2 PCF- Point Coordination Function
En plus de la fonction de base de coordination distribue DCF, il y a la fonction PCF

coordination centralise qui peut tre utilise pour implmenter des services temps rel, comme
la transmission de voix ou de vido. Quand PCF est activ, le canal radio est divis en super-
trames. Chaque super-trame consiste en une priode dite Contention-Free period- CFP pour le
PCF et Contention Period- CP pour la DCF. Au dbut de la CFP, le coordinateur qui est
gnralement le point daccs prend laccs au medium, commence cycliquement interroger
les stations haute priorit en leur envoyant des paquets Contention Free-Poll (CF-Poll) pour
leur donner le droit d'envoyer un paquet. Donc lAP est le coordinateur. Ceci permet une
meilleure gestion de la qualit de service QoS- Quality of Service. Cependant, le PCF prsente
un certain nombre de limitations, par exemple il ne dfinit pas de classes de trafic.

Universit Paris-Est
2.2.3.5 Itinrance et rassociation
Priodiquement, le client explore tous les canaux 802.11 pour dterminer si un autre
point daccs est susceptible de lui offrir de performances suprieures. Sil dtermine que cest
le cas, il se dsassocie du premier point daccs et sassocie au deuxime en se rglant sur le
canal radio de celui-ci [15] ; cette procdure est appele Rassociation ou itinrance (en
anglais handover ou roaming ).
Figure 18 Itinrance entre les points daccs
La plupart des algorithmes de handover sont principalement bass sur le rapport signal sur bruit
(RSB) (les handover se produisent en gnral lorsque la station sest loigne du point daccs
original, entranant par consquent un affaiblissement du signal ou plus prcisment du RSB).
Ces algorithmes peuvent tre diviss en trois catgories [18]:
Premire catgorie: elle est base sur le RSB reu du point daccs seulement. Cette
mthode dcide le handover quand le RSB du point daccs courant est plus petit qu'un
autre point daccs. Ce genre de mthode est simple mais peut causer un transfert rpt
ou inutile.
Deuxime catgorie: elle est base sur RSB relatif un certain seuil (appel en anglais
Cell Search Threshold. Le transfert a lieu quand le RSB moyen tombe au-dessous
d'une certaine valeur seuil et la station se mettra alors chercher un autre point daccs,
dans le but de rester connecte au LAN. Cette mthode peut viter le transfert inutile
quand le signal courant de station est encore satisfaisant.

Universit Paris-Est
Figure 19 Itinrance et rassociation
Dans la figure 19, les RSB reues de 2 APs sont montres pour une certaine position de la
station mobile. Quand la station sloigne de lAP1, le RSB reu de cet AP diminue ; en se
rapprochant de lAP2, le RSB commence augmenter. Quand le RSB baisse au-dessous du
Cell Search Threshold, la station mobile rentre dans la procdure de recherche dune cellule et
commence par le scanning, cherchant seulement les canaux actifs (mettant une probe request
toutes les 2 secondes). Quand la station seloigne davantage, le RSB de l'AP2 devient meilleur
que celui de l'AP1. Une fois que la diffrence entre les deux RSB excde la valeur Delta
RSB , la commutation est faite (position 2). La station restera dans la procdure de recherche
de cellule, jusqu' ce que le RSB ait pass le Cell Search Threshold (position 3).
Une autre situation peut surgir, cest quand une station sloigne de son point daccs, tandis
quil ny a pas dautre AP pouvant offrir un meilleur RSB (cf. figure 20) ; la station enverra des
probe request mais ne recevra pas de rponse. Le RSB continue diminuer jusquau seuil dit
Out of Range Threshold; la station rentre alors dans ltat Out of range state et son dbit
diminuera.
Figure 20 Handover avec un seul AP

Universit Paris-Est
Troisime catgorie: elle est base sur le RSB relatif avec un hystrsis. Le transfert est
lanc seulement si le RSB du nouveau point daccs est suffisamment plus fort que le
point daccs courant avec une marge d'hystrsis. Cette mthode peut empcher l'effet
ping-pong, qui est le scnario du transfert rpt entre deux points daccs d des
fluctuations rapides dans le RSB reu des deux points daccs.
Des procdures de rassociation pourront aussi tre inities dans le cas dun trop fort
niveau dinterfrence qui pourra tre dtect soit par le non rception des trames balises
priodiques, soit par une absence rpte dacquittement. Si dautres APs existent, la station
mobile peut se rassocier une nouvelle cellule. Cest une forme de distribution ou
dquilibrage de charge (load balancing), puisquelle rpartie la charge totale du rseau sans fil
sur linfrastructure sans fil disponible.
Ce processus dassociation/rassociation dynamique aux points daccs permet

ladministrateur du rseau de crer une couverture trs tendue, en faisant chevaucher de
multiples cellules 802.11 sur lensemble dun btiment ou dun campus. Une rutilisation des
canaux peut tre adopte, en prenant soin de configurer chaque point daccs sur des canaux
802.11 diffrents de ceux utiliss par les points daccs contigus car lorsque les rayons daction
de deux points daccs se chevauchent alors quils sont configurs sur un mme canal ou sur des
canaux se recouvrant partiellement, des interfrences sont susceptibles de se produire entre les
deux, avec pour consquence une diminution de la bande passante sur la zone de chevauchement
(cf. figure 21).
Figure 21 Chevauchement des rayons daction des APs
2.2.3.6 Dbit rel et dbit thorique
La norme IEEE dfinit un dbit de transmission allant jusqu' 11Mbit/s pour le 802.11b,
54 Mbit/s pour le 802.11g et le 802.11a et des dbits allant jusqu' 270 Mbit/s ou 300 Mbit/s
pour le 802.11n. Ces dbits correspondent la bande passante des donnes utilisateurs au niveau
de la couche MAC (dbit nominal linterface de la couche MAC). Cependant, la bande
passante offerte un utilisateur WiFi qui est la bande passante relle ou pratique,
correspond au dbit effectif en transmission (cest--dire au dbit utile linterface entre la
couche PHY et linterface air).

Universit Paris-Est
Le protocole mis en oeuvre au niveau de la couche PHY pour accder au medium, le

type de modulation utilis, la taille des paquets transmis, le protocole utilis au niveau de la
couche MAC (CSMA/CA ou RTS/CTS) affectent la bande passante thorique [24]. Dans cet
article, J. Jangeun et P. Peddabachagari ont considr ces facteurs pour calculer la bande
passante thorique maximale. Les rsultats ont montr que le dbit thorique maximal obtenu
avec le CSMA/CA utilis au niveau de la couche MAC est suprieur celui obtenu avec le
RTS/CTS (RTS/CTS implique un nombre lev de trames de contrle); par exemple pour un
dbit initial de 11Mbit/s, le dbit thorique maximal est de 6.06 Mbit/s avec le CSMA/CA et de
4.52 Mbit/s avec RTS/CTS. Dautre part, les auteurs dans [24] dfinissent lefficacit de la
bande passante dune modulation comme le ratio entre bande passante thorique maximale et le
dbit nominal linterface de la couche MAC. Cette efficacit est de lordre de 55 60 % pour
les dbits maximum de chaque modulation (11 Mbit/s pour la modulation CCK et 54 Mbit/s
pour la modulation OFDM), elle atteint 90% pour les dbits les plus faibles de chacune des
modulations (1 Mbit/s et 6 Mbit/s).
Des tudes ont aussi montr que la bande passante maximale atteinte varie dun modle de
points daccs un autre (dun constructeur un autre) [156].
A part les facteurs thoriques qui affectent la bande passante effectivement disponible,
des tudes ont tudi limpact dautres facteurs, parmi lesquels on cite:
- La distance entre la station mobile et le point daccs: on a logiquement un dbit lev quand la
station mobile est proche de la station de base et son dbit baisse quand elle s'loigne d'elle
[165].
- La mobilit des stations mobiles: peu dtudes ont t faites sur la qualit du lien WLAN
quand les noeuds sont en mouvement. Chen et Foreman nont pas remarqu une augmentation
du taux de paquets perdus quand les nuds sont en mouvement durant leur exprience faite en
1995 [147]. Hoene, Gunther et Wlisz [41], ont not que la qualit moyenne du canal pouvait tre
suprieure quand les noeuds sont en mouvement (dans certaines conditions) par rapport la
situation o ils sont fixes. Des tudes ont t aussi faites sur limpact de la mobilit grande
vitesse sur la qualit du lien WiFi ; une tude faite lUniversit de Californie pour des vitesses
allant jusqu 240 km/h montre que dans un espace compltement ouvert, la communication est
trs robuste face leffet Doppler, par contre dans des scnarios de handover ainsi que dans un
espace ferm (avec des obstacles, des trajets multiples, etc), la mobilit a un impact ngatif
sur la performance [42]).
- Le nombre dutilisateurs affectent la disponibilit du lien WiFi. La bande passante est alors
partage entre les diffrents stations mobiles associs un point daccs [164].
- Les interfrences et les obstacles: quand le canal est bruit, la bande passante maximale qui
peut tre atteinte est infrieure celle atteinte avec un canal non bruit [131].
- Lorientation, le gain et la puissance dmission des antennes des points daccs [166].
Dans le chapitre 3 de ce mmoire, dans lequel on propose un nouveau protocole de

communication adapt au type de traffic pour lapplication considre de ce mmoire sur un lien
radio WiFi, on a mesur la bande passante relle avec le 802.11b aux alentours de 5 Mbit/s.
Quand une transmission a lieu sur un canal adjacent interfrent, elle est de lordre 3 Mbit/s.

Universit Paris-Est
Dans le paragraphe 3.7.1.2, on a aussi mesur la bande passante quand la distance sparant
lmetteur et le rcepteur augmente (pour une distance de 10 mtres, on a un dbit environ de 4
Mbit/s) et quand un obstacle existe entre lmetteur et le rcepteur on a un dbit aux alentours de
2Mbit/s. Il faut noter que ces tests sont faits sur du WiFi en mode ad-hoc.
Qualit de Service dans 802.11
Garantir une qualit de service veut dire garantir, pour une certaine communication, un
certain dbit, un dlai limit, un taux derreur acceptable, ...etc. Les premires versions du
standard 802.11 nont pas dfinis des mcanismes pouvant garantir une certaine qualit de
service. Le mode PCF a t dvelopp pour diffrencier les services dans le 802.11 mais sa
performance reste limite. Cependant, avec la large diffusion des rseaux sans fil 802.11, le
besoin en qualit de service devient un enjeu pour les applications multimdias. Cest dans ce
but que le standard 802.11e a t ratifi. Il doit permettre dutiliser le WLAN pour des
applications temps rel comme la voix et le multimdia.
802.11e propose des modifications de la couche MAC [45, 46]. Le mode DCF est
maintenant nomm EDCF (Enhanced DCF) ou HCF (Hybrid Coordination Function), les
stations mobiles Enhanced Stations, le point daccs qui est le coordinateur est nomm HC
(Hybrid Controller) et le BSS QBSS (QoS-supporting BSS). Dautres protocoles et
mcanismes ont t aussi proposs dans le mme but comme le Distributed Fair Scheduling,
Blackburst, Wireless Rether Protocol, Distributed Deficit Round Robin (DDRR), Persistent
Factor DCF (P-DCF), Distributed Weighted Fair Queue (DWFQ), ... [47].
2.3 Golocalisation Techniques et systmes

2.3.1 Gnralits
La golocalisation ou gopositionnement consiste estimer la position gographique
(coordonnes gographiques) d'un objet dans l'espace (sur le globe terrestre) ; plus localement,
on appelle localisation ou positionnement la dtermination de la position de lobjet dans
lenvironnement proche (par exemple : donner les coordonnes cartsiennes dun objet dans un
btiment). Les applications de glocalisation/localisation sont diverses [30]: trouver un mdecin
dans un hpital, surveiller le dplacement dun vhicule, trouver un objet ou un matriel perdu,
localiser des objets dans un entrept, localiser des personnes dans des endroits publics, ... Ce
sujet intresse beaucoup de socits et de chercheurs actuellement. Diffrents systmes,
mthodes et techniques de localisation ont t dvelopps ; on en dresse un tat de lart succinct
dans les paragraphes suivants.
2.3.2 Mthodes et Techniques de Golocalisation

Les systmes de golocalisation/localisation (par la suite on dira seulement localisation)
sont multiples, utilisant des mthodes et des techniques diffrentes (on dsigne par systme, le
nom donn par un constructeur ou un projet une solution de localisation). Cette localisation
peut sappuyer par exemple sur les:
Systmes satellites : par exemple GPS, Galileo, Glonass, Compass,
Systmes WiFi 802.11 : Ekahau, Magic Map, etc. On les appelle WPS pour WiFi
Positioning Systems

Universit Paris-Est
Technologies sans fil courte distance : Bluetooth, Infrarouge, Zigbee, UWB,

Systmes de communications cellulaires : positionnement dun tlphone portable via la
connaissance des cellules GSM ou UMTS. Systme Ootay, GlobalMPS,
Internet : se basant sur ladresse IP et sur une base de donnes de rpartition de ces
adresses
Signaux de tlvision (TV) : systme ROSUM
Ces systmes diffrent par leur utilisation et les informations de positionnement quils
fournissent: certains fonctionnent en zone extrieure (les systmes de localisation par Satellite),
d'autres peuvent aussi fonctionner en zone intrieure (WPS) ; certains peuvent dterminer la
position de l'objet en deux dimensions (2D), d'autres en trois dimensions (3D)...etc. Ils diffrent
aussi par les mthodes et les techniques de positionnement quils utilisent.
Les mthodes de golocalisation peuvent tre divises en trois catgories:
Mthodes gomtriques : utilisant les thormes gomtriques sur les relations dans les
triangles en particulier,
Mthodes statistiques : mthode d'empreinte radio (radio fingerprinting) par exemple,
Mthodes hybrides : utilisant une combinaison de mthodes gomtriques et statistiques
[31].
Parmi les principaux paramtres mesurs par les mthodes de localisation, on peut citer :
Temps darrive ou ToA - Time of Arrival
Diffrence de temps darrive ou TDoA - Time Difference of Arrival
Angle darrive ou AoA - Angle of Arrival
Puissance (ou indicateur de puissance) du signal reu ou RSS- Received Signal Strength.
Gnralement dans un systme de localisation, on dispose de points de rfrence (PR) et

dun objet souvent mobile (OM) dont on cherche dterminer la position par rapport aux PR.
Les algorithmes de positionnement et les calculs se font soit au niveau des PR soit dans les OM.
2.3.2.1 Mthodes gomtriques
Ce sont les mthodes qui se basent sur les thormes gomtriques pour le calcul des
distances et/ou des angles [81].
Trilatration
Cette mthode permet de positionner un OM en 2D laide de trois PR. Elle consiste

mesurer les distances (en utilisant lune des techniques de mesure de distance dtailles dans le
paragraphe 2.3.3), qui sparent le point positionner des PR. On trace ensuite un cercle autour
de chaque PR dont le rayon est gal la distance mesure entre le PR et lOM. La position de
lOM se situe lintersection de ces trois cercles.

Universit Paris-Est
Triangulation
Dans cette mthode, deux PR de coordonnes connues forment avec lOM un triangle.
On utilise ensuite les proprits gomtriques des triangles pour calculer la position de lOM : la
loi des sinus, le thorme dAl Kashi, le thorme de Pythagore, etc.
Cette mthode utilise donc moins de PR que la mthode de trilatration mais ncessite la
connaissance de plus dinformations liant les trois noeuds. Il est ncessaire de connatre les
angles du triangle form par les trois nuds et la distance entre les points de rfrence.
La triangulation est divise en sous-catgories de latration et dangulation [33]. La latration

est le terme employ pour des mesures de distance. Elle consiste calculer la position d'un objet
en mesurant sa distance aux PR. Un calcul de position en 2D exige des mesures de distance de 3
PR non colinaires; pour des mesures en 3D, 4 PR non coplanaires sont requis.
Langulation est employe pour des mesures dangle. Une localisation dangle en 2D exige
gnralement deux mesures d'angle et une mesure de longueur telle que la distance entre les PR ;
en 3D, une mesure de longueur, une mesure d'azimut, et deux mesures d'angle sont ncessaires
[85].
2.3.2.2 Mthodes Statistiques
Ce sont les mthodes qui consistent effectuer des mesures rfrences puis
comparer les mesures ralises pour lOM avec ces mesures de rfrences pour en dduire la
position de lOM. Ces approches comprennent donc deux tapes : une tape de calibrage ou
dapprentissage et ltape destimation de la position. Une des mthodes les plus efficaces est la
mthode dempreinte radio (en anglais RF fingerprinting), qui se base sur les mesures des
puissances reues (RSSI pour Received Signal Strengh Indicator) par lOM partir de balises
radios (comme les points daccs WiFi par exemple).
Empreinte radio
La mthode d'empreinte radio se fait en deux phases : Formation (calibrage ou

apprentissage) et Positionnement (localisation) (appeles en anglais Training et
Positioning ou encore Off-line training phase et Real-time or Online location
determination phase).
Durant la phase de formation, des mesures de RSS sont prises : des balises radios sont installes
sur le site dsir, des points chantillons (des positions sur le site) sont choisis et les RSS
mesurs et sauvegards dans une base de donnes.
Pendant la phase de positionnement, la position de l'OM est dtermine en comparant les RSS
mesurs par lOM avec les RSS sauvegards dans la base de donnes (appele carte radio ou
map). Plus le nombre de balises radios augmente, plus la prcision samliore [32] ; plusieurs
mesures successives de puissance doivent tre ralises pour une meilleure valuation de la
position, les ondes radios tant affectes par plusieurs facteurs.
Les besoins de calibrage et de mise jour de la base de donnes sont les inconvnients de cette
approche. (Nous dtaillons cette mthode dempreinte radio et les algorithmes utiliss pour le
calcul de position dans le chapitre 4).

Universit Paris-Est
2.3.2.3 Mthodes Hybrides
Des mthodes hybrides ont t proposes. Elles comportent deux tapes : dans la
premire tape, elles utilisent la mthode d'empreinte radio avec une phase rapide de formation
(ceci indique quon a peu de PR et que la base de donnes est trs petite) pour obtenir une
premire valuation de positionnement (indiquant par exemple dans quelle pice du btiment se
trouve lOM), et dans la deuxime tape, un modle empirique prcis de la propagation du
signal sera utilis pour calculer la distance exacte entre metteur et rcepteur ; la triangulation
pourra alors tre utilise pour calculer la position de lOM plus prcisment [31].
2.3.3 Techniques de mesure

Les distances et les angles dans les mthodes de positionnement dj cites sont mesurs
selon plusieurs techniques de mesure ; on peut citer : temps darrive, diffrence de temps
darrive, angle darrive et puissance du signal reu (RSS- Received Signal Strength).
Temps dArrive (ou ToA pour Time of Arrival)
Cette technique se base sur le temps de propagation du signal. La source envoie un signal
dat au rcepteur qui date son tour son heure darrive. Un systme de golocalisation va alors
se baser sur ces informations pour en dduire la distance metteur-rcepteur en supposant le plus
souvent que la propagation se fait en ligne directe. Une synchronisation complte entre
lmetteur et le rcepteur est ncessaire pour des calculs prcis.
Diffrentiel de temps darrive (ou TDoA pour Time Difference of Arrival)
Le principe est similaire au ToA, mais en utilisant une source quelconque qui ne date pas
son mission. Le signal est alors reu par les rcepteurs et le systme de golocalisation
dtermine la position de la source en fonction de la diffrence des temps darrive sur les
rcepteurs. Cette technologie exige de mme une horloge trs prcise et trs bien synchronise
au niveau des rcepteurs.
Cette solution est bien adapte dans les environnements ouverts o le signal se propage en ligne
directe (on utilise le term LOS line of Sight). Comme lapproche TOA, elle peut connatre des
limites en intrieur cause des obstacles et des effets de rflexion, rfraction ou diffusion.
Angle darrive (ou AoA pour Angle of Arrival)
Utilise par les radars ariens, cette technique consiste calculer langle de rception
dun signal par 2 ou 3 radars, et, en utilisant cette information, positionner lobjet dans lespace.
Elle est trs prcise, mais demande des antennes motorises (ou balayage lectronique) pour
dterminer langle de rception.
Puissance du signal reu (ou RSSI pour Received Signal Strength Indicator)
La position de lOM est dtermine daprs la puissance du signal reu de la part de

balises radios (comme des points daccs WiFi par exemple). Elle exploite l'attnuation du
signal due la distance. Mais la faon dont la puissance varie en fonction de la distance dpend
du milieu et nest pas toujours connue avec prcision. De plus, la propagation des ondes
lectromagntiques est affecte par plusieurs facteurs comme les pertes dues aux obstacles,

Universit Paris-Est
leffet des trajets multiples, les interfrences gnres par d'autres signaux, etc. Dans la bande de
frquence de 2.4 gigahertz de WiFi par exemple, les sources dinterfrences possibles sont
nombreuses car il sagit dune bande de frquences libre utilise par de nombreux systmes
(fours micro-ondes, les dispositifs Bluetooth par exemple). L'orientation de l'antenne du
rcepteur, le mouvement et le dplacement de lOM peuvent aussi affecter le RSS dune manire
significative. Cette technique suppose que le modle dattnuation des lieux (obstacles, murs)
soit bien connu, ou appris par calibration bien quil soit extrmement difficile d'tablir un
modle gnral suffisamment bon de la propagation du signal qui concide avec la situation
relle.
2.3.4 Systmes de localisation

Dans cette section nous apportons quelques prcisions sur les systmes de
golocalisation cits dans le paragraphe 2.3.2 et qui utilisent les diffrentes mthodes et
techniques de positionnement, en essayant de donner les avantages et les inconvnients de
chacun deux.
2.3.4.1 Localisation par Satellite
Global Positioning System (GPS)
Le systme GPS [91] qui peut tre traduit en franais par systme de positionnement
mondial ou encore selon lacronyme GPS par gopositionnement par satellite , est un
systme dorigine amricaine qui se base sur la mthode de trilatration et sur le temps de
propagation du signal pour dterminer la position en 3D dun objet sur le globe.
Il se compose de trois parties distinctes appeles segments : le segment spatial constitu
actuellement dune constellation de 31 satellites, voluant sur 6 plans orbitaux quasi circulaires,
le segment de contrle qui permet de surveiller et de contrler en permanence le bon
fonctionnement du systme est compos de cinq stations au sol dpendant exclusivement des
USA et dont la station (MCS pour Master Control Station) est implante Colorado Springs, et
le segment utilisateur qui regroupe l'ensemble des rcepteurs GPS qui reoivent et exploitent les
informations des satellites.
Le principe de localisation est en lui mme trs simple. En effet, si on imagine de vouloir
localiser un point M, de la surface du globe terrestre, il suffit d'entrer en contact avec 3 satellites
(4 si on veut un positionnement en 3D). Chaque satellite envoie son numro d'identification, sa
position prcise par rapport la terre, ou dans le repre li Greenwich, l'heure exacte
d'mission du signal ; le rcepteur GPS recevant le signal, grce son horloge suppose
synchronise sur celle des satellites, en dduit sa distance au satellite. Le GPS travaille en 3D et
le principe de calcul sappuie sur lintersection de sphres : le point M est sur une sphre de
rayon D1 et de centre le satellite S1, l'intersection avec le globe donne un premier cercle C1 ; Le
point M est aussi sur une sphre de rayon D2 et de centre le satellite S2 et sur une sphre de
rayon D3 et de centre le satellite S3 ; l'intersection de ces sphres avec le globe donne deux
autres cercles C2 et C3 ; le point M se trouve alors lintersection de ces trois cercles.

Universit Paris-Est
.
Figure 22- Principe de localisation GPS
La prcision fournie par le GPS civil est estime aux alentours de 15 mtres dans 95% des cas
pour un fonctionnement de type temps rel . Il est cependant difficile de donner des chiffres
de prcision sans prciser les conditions et mthodes de mesure (en particulier la dure de ces
mesures). Cette prcision dpend de plus la visibilit des sattellites par le rcepteur et de la
qualit de lantenne utilise. Le GPS est lun des systmes de positionnement les plus populaires
en milieu extrieur ; cependant, il n'est pas appropri certains environnements spcifiques, tels
qu' l'intrieur des btiments ou dans certains environnements urbains denses (on parle de
canyons urbains parfois).
DGPS
Differential Globlal Positioning System ou GPS diffrentiel permet d'amliorer la

prcision du GPS en rduisant la marge d'erreur du systme. Il est bas sur un ensemble de
stations fixes la surface de la terre, dont la position est connue trs prcsiment ; celles-ci
reoivent les signaux des mmes satellites que les terminaux mobiles prsents dans leur zone
d'action, et estiment en permanence l'erreur locale de positionnement du GPS en comparant la
position calcule avec leur position relle. Cette information est transmise par radio ou par
satellite au rcepteur GPS afin de lui permettre de corriger une grande partie des erreurs de
mesure, qu'elles soient lies au satellite (horloge), aux conditions de propagation (effets
troposphriques, etc.) ou des fluctuations volontaires du signal mis. On peut ainsi passer d'une
prcision de l'ordre de 15 mtres une prcision de 5 3 mtres.
GLONASS
Systme GLObal de NAvigation par Satellite est le nom du systme de positionnement

utilis par la Russie. Il repose aussi sur une constellation de 24 satellites mis dans 3 plans
orbitaux (8 satellites pour chaque plan orbital), dont, depuis 2008, 16 satellites sont actifs et en
orbite. L'Agence spatiale fdrale russe (Roskosmos) prvoit la fin du dploiement des 24
satellites couvrant le monde entier vers la fin 2009. La partie au sol est forme de cinq stations
de contrle, la principale se trouve dans la rgion de Moscou [75].

Universit Paris-Est
Les utilisateurs du systme, comme pour le GPS, doivent disposer dappareils de positionnement
quips de rcepteurs spcifiques.
Comme le GPS GLONASS ne peut pas tre utilis lintrieur des btiments, la puissance des
ondes radios reues des satellites tant trop attnue par les murs.
EGNOS
EGNOS ou European Geostationary Navigation Overlay Service est le premier systme

europen utilisant les ondes des satellites et qui a pour but damliorer la prcision des deux
systmes GPS et GLONASS. Il utilise les constellations de satellites GPS et GLONASS et
sappuie sur une quarantaine de stations terrestres. Ces stations terrestres. Elles constituent un
maillage serr qui complte trs utilement la triangulation obtenue partir des satellites du GPS.
Elles reoivent les signaux des constellations de satellites et diffrentes donnes
climatologiques. Elles communiquent avec des centres de contrle qui exploitent les
informations reues et transmettent le rsultat des corrections diffrentielles un satellite
gostationnaire ((INMARSAT-3 AOR-E, INMARSAT-3 IOR ou ESA ARTEMIS). Ces
satellites gostationnaires peuvent ensuite les communiquer aux rcepteurs des utilisateurs. Une
prcision de 20 m obtenue avec le GPS peut passer une prcision de 2 mtres avec EGNOS,
avec des signaux fiables. Il est prvu que ce systme soit compltement dploy la fin de 2009
[75].
Galileo
Le systme EGNOS prfigure Galileo. Galileo a pour but de supprimer la dpendance de

lEurope du systme amricain GPS. Il sappuie sur une constellation de 30 satellites en orbite
moyenne. Il est prvu que dans quelques annes (implmentation prvue en 2014-2015) Galileo
fournira une bonne prcision de positionnement et diffrents types de qualit de service [27, 74,
75].
2.3.4.2 WiFi Positioning System (WPS)
Le GPS utilise une combinaison de satellites pour dterminer les coordonnes de la

position dun objet. Bien que sa couverture de la surface du globe terrestre soit trs bonne, il ne
peut pas tre utilis correctement dans les milieux intrieurs car les signaux satellites ne sont pas
toujours assez puissants pour pntrer dans ces zones (on parle de localisation indoor ou outdoor
pour la localisation lintrieur des btiments ou lextrieur des btiments) ; dautre part, le
dploiement dinfrastructures spcifiques ddies la localisation indoor peut avoir un cot
important pour une utilisation limite. Il est donc utile de concevoir un systme de
positionnement qui peut utiliser les infrastructures existantes (utilise pour la communication ou
pour d'autres buts) et qui soit utilisable en indoor et en outdoor pour permettre une continuit de
service. Les systmes de positionnement utilisant les ondes radio WiFi ont t proposs dans ce
but et deviennent de plus en plus rpandus.
Le gopositionnement l'aide de la technologie Wi-Fi est baptis WPS pour Wi-Fi

Positionning System. En comparaison avec le GPS, le WPS remplace linfrastructure des
satellites par les infrastructures radios des rseaux Wi-Fi et dispose de plusieurs atouts :

Universit Paris-Est
- Sa couverture intrieure et extrieure, lui permettant, au contraire du GPS, de continuer

fournir un go-positionnement relativement prcis en indoor et dans certaines zones urbaines
denses avec des effets de canyon urbain. La technologie donne mme les meilleurs rsultats
dans un environnement particulirement dense, en raison de la multiplication des points
d'accs.
- Il n'implique pas de matriel supplmentaire, l'quipement Wi-Fi tant dj prsent au sein

des diffrents appareils de communication.
Il prsente cependant des inconvnients :
- WPS pose un problme de couverture en environnement rural ou dans des zones peu
quipes en points d'accs Wi-Fi.
- Les points d'accs WiFi sont des rcepteurs plus mobiles que les infrastructures GPS, ce qui
peut fausser les calculs si les bases de donnes ne sont pas mises jour rgulirement.
Daprs le pragraphe 2.3.2, plusieurs techniques de mesure (ToA, TDoA, AoA, RSS)
existent pour le calcul des distances et des angles dans les systmes de golocalisation utilisant
les ondes radio. Cependant, la mthode ToA est peu envisageable pour du WiFi car les points
daccs ne sont pas synchroniss avec les rcepteurs ; de mme dans la TDoA, les points daccs
radio doivent avoir une horloge trs prcise et bien synchronise. Des systmes comme
AirLocation [76] et AeroScout [77] utilisent cette technique TDOA mais ncessitent du
matriel supplmentaire (des points daccs ou des rcepteurs spcifiques) pour mesurer cette
diffrence de temps. La technique AoA demande des antennes motorises (ou balayage) pour
dterminer langle de rception et est peu utilise actuellement avec les antennes des points
daccs WiFi mais larrive des systmes MIMO WiFi pourrait modifier cette situation. La
technique base sur le RSS est la plus souvent utilise en WiFi, elle suppose cependant que le
modle dattnuation des lieux (obstacles, murs) soit bien connu, ou appris par calibration.
Plusieurs systmes utilisant le WPS sont disponibles sur le march ou dans les laboratoires de
recherche. On peut citer :
Skyhook Wireless
Ce systme de la socit Skyhook se base sur la triangulation. Un calcul de position

ncessite l'activation d'un logiciel client sur le terminal mobile qui balaie les ondes hertziennes
la recherche des signaux 802.11 [28]. Une fois ces informations obtenues, il recoupe les
diffrents signaux et calcule la distance actuelle partir des diffrentes donnes gographiques
stockes dans une base de donnes. Sur le client tourne un algorithme qui calcule la position
temps-rel ainsi que la vitesse. Le client inclut galement des techniques avances de filtrage et
doptimization de la base de donnes pour amliorer continuellement le systme. Le
positionnement offert prsente une prcision comprise entre vingt et quarante mtres.
La base de donnes de lieux contient une des listes les plus compltes des points d'accs Wi-Fi
gopositionns pour lAmrique du Nord. Elle est continuellement mise jour avec de nouvelles
rgions des Etats-Unis et du Canada et avec de nouvelles donnes des zones de couverture
existantes. La collecte de donnes commence par identifier des secteurs gographiques cibles en
utilisant l'analyse de population. Les planificateurs de territoire de Skyhook ralisent linventaire
des points daccs existants dans les centres publics ainsi que dans les secteurs rsidentiels et

Universit Paris-Est
suburbains. Skyhook emploie des vhicules de collecte de donnes pour mener une enqute
complte sur les points d'accs dans les rgions cibles. Chaque rgion est continuellement
surveille pour valuer la qualit du rseau rfrence et pour dterminer si une mise jour est
ncessaire.
Systme Ekahau Real Time Location System (RTLS)
La technique de positionnement propose par la socit Ekahau est base sur la

technique d'empreinte radio, base sur les mesures des puissances des signaux reus (RSSI) (cf.
paragraphe 2.3.2.2) et comporte deux phases de formation et de positionnement. Ce systme
consiste en :
- des clients agents : logiciel intgrs dans un objet tel quun smartphone positionner,
- des tiquettes Ekahau portes par les dispositifs localiser (optionnelles),
- le serveur de positionnement (EPE pour Ekahau Positioning Engine) qui calcule les
estimations de position,
- le logiciel de cration du modle radio (Ekahau Manager) pour la construction de la carte
radio (le calibrage du site) et la gestion du systme.
Le client agent mesure les RSSI reus des diffrents points d'accs et envoie ces mesures au
serveur de positionnement qui calcule la position de lobjet abritant le client agent, en comparant
les mesures transmises par le client aux mesures rfrences prsentes dans la base de
donnes. Les algorithmes utiliss par Ekahau pour la localisation sont dcrits dans le chapitre 4
de ce mmoire).
Plusieurs systmes assez proches de celui dEkahau existent comme Horus de luniversit du
Maryland [34], CMU-TMI [78, 146], Place Lab [114], Magic Map [35], AMULET
(Approximate Mobile User Location Tracking System) de luniversit de Rochester [79, 80],
Halibut [79, 80] de luniversit de Stanford, le systme de la socit Cisco (solution Cisco nified
wireless) [115].
Le temps de calibrage (qui est actuellement effectu manuellement en utilisant un

terminal mobile et en se dplaant dans le site pour enregistrer des points chantillons) ainsi que
la mise jour rgulire de la base de donnes constituent linconvnient majeur de ces systmes
Par exemple, pour calibrer un site de 1200 m2, il faut au minimum 1 heure pour le systme
Ekahau [40].
2.3.4.3 Systmes de localisation par ondes radiofrquences ou infrarouges
On parle dans cette section de quelques autres systmes de localisation utilisant les ondes
radiofrquences, les systmes ultra-large bande (Ultra Wideband ou UWB), les infrarouges,
[86].
RADAR
Propos par P. Bahl et V. Padmanabhan en 2000, RADAR ft le premier systme

adopter la mthode dempreinte radio deux phases de calibrage et de positionnement utilisant
les ondes radiofrquences mises partir dinterfaces rseaux radiofrquences (WiFi entre

Universit Paris-Est
autres mais pas exclusivement) [38]. La prcision de localisation obtenue tait aux alentours de
2 3 mtres.
Active Badge
Ce systme utilise les ondes infrarouges (IR). Une tiquette porte par une personne
met un signal IR toutes les 10 secondes. Des capteurs placs dans des endroits spcifiques du
site captent ces signaux et les envoient un logiciel de localisation qui estime la position de
ltiquette [157].
Cricket
Le systme conu par le MIT utilise une combinaison des ondes RF (Radio frquence) et
des ondes ultrasons. Des balises Cricket beacons prsentes dans le site envoient des ondes
RF et ultrasonores aux rcepteurs Cricket listeners attachs aux OM. LUOM estime sa
position en tenant compte de la diffrence entre le temps de propagation des ondes RF et des
ondes ultrasonores [39].
Ubisense
Le systme Ubisense utilise la technologie UWB. Des tiquettes Ubisense tags sont
ports par lOM et des capteurs Ubisense sensors sont placs sur le site. Les tags envoient
des signaux UWB impulsionnels de trs courte dure qui sont capts par les capteurs et
communiqus un logiciel spcifique qui estime la position de lOM. Le site est divis en
cellules de forme rectangulaire ayant chacune ses capteurs.
Uhuru
Dans ce systme, le calcul de positionnement se fait au niveau des OM. La mthode

statistique est utilise avec les deux phases de formation et de positionnement, mais cest lOM
qui enregistre les diffrents signaux des stations de base avec leurs adresses MAC et fait le
calcul pour estimer sa position [37].
2.3.4.4 Systmes de localisation utilisant la diffusion des signaux de tlvision
Systme de la socit ROSUM corporation
Ce systme se base sur les quipements de diffusion des signaux de tlvision

notamment sur les rseaux de tlvision numrique ATSC DTV et DVB-H. Ces signaux sont
relativement basse frquence et souffrent peu des effets de la propogation ionosphrique et de
leffet Doppler [36]. ROSUM a t test dans des milieux intrieurs et a montr une bonne
prcision. Cependant la performance dpend toujours des signaux de tlvision et de leur
couverture, des niveaux dattnuation et des effets de multi-trajets dans le milieu considr.
2.3.4.5 Systmes de localisation utilisant les systmes de communications cellulaires
Ces systmes sont aussi appels systmes de positionnement mobile (MPS pour Mobile
Positioning System); ils consistent dterminer la position dun tlphone mobile. Un tel

Universit Paris-Est
service est offert comme une option de la classe de services golocaliss (Location Based
Services (LBS)) des oprateurs de tlphones mobiles. Cette technologie est base sur les
mesures de puissance et les diagrammes d'antennes et utilise le concept d'un tlphone portable
sans fil qui communique toujours avec l'une des stations de base (BS pour Base Sation) servant
une cellule du systme [154]. Donc connaissant avec quelle station de base le tlphone portable
est en train de communiquer, le systme peut estimer sa position. Dans les zones rurales cette
estimation nest pas trs prcise vue la grande taille des cellules ; cependant pour des
localisations plus prcises, les techniques comme la mesure dangle darrive ou de temps
darrive sont aussi utilises ainsi quune combinaison de MPS et de GPS. Un exemple de ces
systmes est le 4TS dSeal lanc en 2008 par un fournisseur de solutions de positionnement
finlandais, appel 4TS Finland Oy [83] utilisant une combinaison de GPS et de MPS (appel
GlobalMPS par la socit 4TS) ; il permet un positionnement des dispositifs mobiles
indpendant de l'oprateur, partout o un rseau GSM est disponible (donc aussi l'intrieur des
btiments).
Le systme Ootay [82] est un systme MPS. Lutilisateur dOotay peut se connecter sur
lInternet et visualiser, en temps rel, la position dun tlphone portable ; cette position lui est
communique aprs estimation, travers lInternet, par loprateur mobile GSM.
2.4 Conclusion
La premire partie de ce chapitre a t consacre ltude et la comparaison de
diffrentes technologies de communication sans fil courte distance : Zigbee, Blueetooth et WiFi.
Le choix dune technologie pouvant tre adapte au principe de fonctionnement du systme
RAMPE/INFOMOVILLE dpend de plusieurs facteurs : la disponibilit de cette technologie
dans les dispositifs mobiles pouvant tre ports par les utilisateurs du systme et dans les
quipements de lapplication, sa porte devant stendre sur plusieurs mtres afin de permettre la
communication entre le dispositif de lutilisateur et le dispositif install dans les stations de
transport (bus dans le cas actuel de RAMPE/INFOMOVILLE), la possibilit de lutiliser pour
une future intgration de services (services temps rel, service de localisation, etc). La
technologie WiFi savre la plus satisfaisante du point de vue des aspects suivants : grande
disponibilit des cartes WiFi dans les PCs portables, les ordinateurs de poche (PDA), les
tlphones mobiles ( la diffrence de Zigbee qui est peu utilis dans les tlphones ou PDA
pour le moment), grande porte pouvant aller jusqu des dizaines de mtres (suprieure celle
de Bluetooth), la possibilit de son utilisation pour des services temps rel comme la voix et la
vido (802.11e pour la qualit de service), sa grande utilisation actuelle dans les systmes de
localisation et de positionnement...
Ce dernier point a occup la deuxime partie de ce chapitre avec un tat de lart des diffrents
systmes, techniques et mthodes de positionnement actuellement dvelopps et implments :
systmes de localisation par ondes satellitaires, ondes cellulaires, ondes radiofrquences, ondes
radio WiFi, signaux de tlvision, etc. On cherche dans cette thse un systme de
positionnement bien adapt au service quon dsire offrir et intgrer avec
RAMPE/INFOMOVILLE, qui est la localisation dune personne aveugle et son orientation vers
la station ou la destination dsire. Les systmes de positionnement par satellites sont largement
dploys et assurent une trs bonne couverture internationale mais ils prsentent des limitations
quand ils sont utiliss en indoor et la prcision quils offrent est limite sur dans certains
environnements urbains (rue troite borde dimmeubles levs par exemple). Il est intressant
pour notre application de pouvoir utiliser linfrastructure existante pour intgrer le service de
guidage. Dautre part, nous souhaitons pouvoir utiliser la localisation en outdoor et en indoor du

Universit Paris-Est
fait que le systme RAMPE/INFOMOVILLE devrait pouvoir tre tendu tous les moyens de
transport public (METRO, RER, etc) et quil est important de dassurer une continuit de
service ; une bonne prcision est aussi un critre considrer pour le systme retenu, tant
donn quil est destin des pitons aveugles.
De ce fait, la localisation base sur les systmes WiFi savre tre intressante et adquate pour
notre application. Les systmes WPS prsentent aussi des inconvnients dj discuts dans le
paragraphe prcdent auxquels on a essay de remdier dans cette thse. Les solutions proposes
sont prsentes dans le chapitre 4.

Universit Paris-Est
Chapitre 3- RAMPE/INFOMOVILLE Application Protocol
Chapitre 3
RAMPE/INFOMOVILLE Application Protocol
3.1 Introduction et objectifs
Lobjectif du projet RAMPE/INFOMOVILLE est de fournir un systme dassistance aux
personnes dficience visuelle pour leurs dplacements dans les transports publics. La
conception dun systme utilisant les technologies de communication les plus rcentes doit
mettre lutilisateur final au centre des proccupations afin de lui fournir un service de qualit. On
tudie dans ce chapitre la qualit de service du systme RAMPE/INFOMOVILLE de point de
vue technique. Cette qualit se dfinit par la disponibilit du service et sa fiabilit.
RAMPE/INFOMOVILLE sappuie sur deux technologies: les PDA et WiFi. Le PDA sur lequel
tourne lapplication RAMPE/INFOMOVILLE communique avec les bornes installes dans les
stations travers le rseau WiFi; il constitue donc une ressource entirement ddie ce systme
linverse du rseau WiFi qui est partag entre plusieurs utilisateurs. Etudier la fiabilit et la
disponibilit de RAMPE/INFOMOVILLE revient alors tudier les performances de cette
technologie de communication sans fil.
Un rseau est considr comme fiable sil permet au rcepteur de recevoir les informations telles
quelles ont t transmises. Diffrents protocoles, oprant travers linterface WiFi sont utiliss
pour la communication entre les diffrents composants de RAMPE/INFOMOVILLE. Etudier la
fiabilit du service consiste alors tudier la fiabilit de ces protocoles.
On dtaille dans ce chapitre les diffrents protocoles utiliss dans

RAMPE/INFOMOVILLE. Les trames changes entre le PDA et la borne sont de plusieurs
types; certaines sont changes en utilisant le protocole TCP, en transmission unicast, qui est
suppos tre fiable, car cest un protocole orient connexion de la couche de transport du modle
OSI. Dautres trames utilisent le protocole UDP qui est un protocole non orient connexion; il
est utilis en mode broadcast pour la transmission des trames et messages urgents. Plusieurs
techniques ont t proposes dans le but damliorer la fiabilit dune transmission UDP sur
WiFi spcifiquement la transmission en mode broadcast.
On propose dans ce chapitre un nouveau protocole dans le contexte de ce type

dapplication [12] qui pourra tre appropri au type de trafic que lon rencontre dans
RAMPE/INFOMOVILLE. Cette proposition aura un double intrt: le premier sera ltude dun
protocole qui fiabilisera la communication entre PDA et point daccs pour la transmission en
broadcast des messages temps rels, et le deuxime est ergonomique: tudier la possibilit de
fournir lutilisateur du systme un indicateur de qualit de la liaison qui le relie au point
daccs et par suite un degr de confiance en lapplication. On dtaille le principe du protocole
propos, on simule son fonctionnement et on le compare au protocole utilis dans la version
actuelle de RAMPE/INFOMOVILLE.

Universit Paris-Est
3.2 Indicateur de qualit dun lien WiFi

Plusieurs facteurs affectent la qualit du lien WiFi et par suite celle dune
communication travers ce lien. Etudier les performances dune communication radio revient
tudier la fiabilit du lien radio travers lequel cette communication entre les diffrentes entits
est tablie. Ce lien dondes lectromagntiques est susceptible aux erreurs, vulnrable aux
perturbations surtout lorsque des obstacles existent entre lmetteur et le rcepteur: rflexion,
rfraction, diffraction, plusieurs chemins parallles dcals dans le temps, absorbtions,
(phnomnes daffaiblissement du signal et dvanouissement rapide du signal), etc ; les
ondes radios sont aussi affectes par les bruits et les interfrences de la part dautres rseaux
lectromagntiques proximit, la mobilit des utilisateurs, etc (cf. chapitre 2), etc La
fiabilit est aussi affecte par sa disponibilit: un manque de ressources ou un taux doccupation
lev induiront des collisions et des pertes de paquets de donnes ce qui affectera la fiabilit de
la communication; dans tous les cas, cest la bande passante disponible vu de lutilisateur qui est
affecte ce qui affectera par la suite la qualit de la communication.
La qualit du lien Wifi peut tre mesure selon plusieurs mtriques: Puissance Reue
(RSSI pour Received Signal Strength Indicator), Rapport Signal sur Bruit (RSB) (SNR pour
Signal to Noise Ratio), Rapport Signal sur Interfrences plus Bruit (SINR pour Signal-to-
Interference-plus-Noise Ratio), Taux dErreurs Paquet (PER pour Packet-Error Rate), Taux de
Livraison Paquet (PDR pour Packet-Delivery Ratio) et Taux dErreurs Bit (BER pour Bit-Error
Rate). Des exprimentations et des observations ont montr quaucune de ces mtriques, utilise
comme seul indice, ne permet de dterminer dune faon prcise la qualit du lien radio 802.11
[44]. Le RSSI par exemple nest mesur seulement que lors de la rception prambule du paquet
qui est transmis un faible dbit, ne peut pas dterminer prcisment la qualit du lien, surtout
lors des transmissions haut-dbit ; il ne permet pas, dautre part, de dtecter prcisment les
fluctuations des interfrences. Le BER constitue un bon indicateur de la qualit du lien,
cependant il doit tre mesur en continue sur des priodes de temps tendues. Quant au PDR, il
est considr comme une bonne mtrique dindication de la qualit du lien WiFi, mais il dpend
de plusieurs facteurs dont la taille des paquets et le dbit de transmission.
Dans ce chapitre on propose un nouveau protocole de communication ajoutant une certaine

fiabilit au canal radio et adoptant un mcanisme de redondance pour la transmission des
paquets amliorant ainsi le taux de rception de ces paquets par lentit destinataire. Dans cette
proposition, le PER sera alors considr comme la mtrique indicatrice de la qualit du lien
radio WiFi ; les exprimentations faites au niveau de ce chapitre observeront ce taux de perte
paquets pour comparer la fiabilit du protocole propos celle dautres protocoles existants.
Le canal radio WiFi est un lment technologique cl de lapplication RAMPE/INFOMOVILLE

travers lequel lutilisateur peut se connecter la ressource dinformation. La confiance en ce
systme dassistance est donc dtermine par la qualit de ce canal radio. Lapplication doit
donc tre mme de pouvoir fournir un indicateur de haut-niveau, cest dire un niveau de
confiance permettant dalerter lutilisateur de cette qualit et donc du degr de confiance quil
pourra avoir dans lapplication. Les interfaces WiFi fournissent deux types dindicateurs un bas
sur le RSSI donnat la qualit du lien dont nous avons voqu les limites ci-dessus et un
indiquant le dbit utilis qui nest pas directement expoitable pour une personne non familire
avec ces technologies.

Universit Paris-Est
Le but du protocole propos dans ce chapitre est de pouvoir fournir lutilisateur de

RAMPE/INFOMOVILLE, un indicateur sur la qualit du lien WiFi base sur la mtrique PER,
qui a lavantage de ne pas ncessiter laccs aux couches basses du device-driver WiFi pour
rcuprer les informations de RSSI et de dbit et de reflter plus fidlement la qualit de la
liaison vu de lutilisateur.
3.3 Modlisation dun canal radio 802.11

Le canal radio, dans un contexte de mobilit est non stationnaire, dans [23] les auteurs
proposent un modle de chane de Markov N tats, dans chaque tat le canal est considr
comme symtrique.
Le modle Gilbert-Elliot (GE) est un canal de Markov deux tats: Bon et Mauvais, utilis pour
la simulation des canaux radios; chaque tat est caractris par une probabilit derreurs au
niveau bit (BER pour Bit Error Rate), une probabilit de transition Pxy vers le deuxime tat
ainsi quune probabilit de rester dans le mme tat.
Figure 23- Les deux tats du modle de canal de Gilbert-Elliot
Le BER dpend gnralement de la frquence, du type de codage utilis et aussi des conditions
environnementales. Ce modle de canal est un modle au niveau bit; sa simulation est lourde et
demande beaucoup de temps du fait que les bits sont analyss lun aprs lautre (pour la
vrification des erreurs); deux expriences de Bernoulli doivent tre effectues chaque bit: la
premire sert dterminer si le bit est erronn et la deuxime dterminer une transition dtat.
Ce modle de simulation est appel Straightforward par les auteurs [23]. Ils proposent des
solutions utilisant un modle de Gilbert-Elliot permettant de passer du niveau Bit au niveau
Paquet (pour le calcul du PER- Packet Error Rate); le but est dacclrer les simulations des
rseaux sans fil tout en obtenant la mme qualit de lestimation du taux derreurs que celle
obtenue avec les simulations au niveau bit.
Le modle Amlior de simulation (appel Improved Simulation Model) a t valu dans en
premier temps: dans ce modle, la probabilit de transition entre deux tats nest plus value
pour chaque bit, mais on considre le temps de sjour dans un tat qui correspond une loi
gomtrique, ltat du canal est donc considr comme pouvant changer chaque x bits tel que x
suit une loi gomtrique, et le calcul des erreurs se fait bit par bit sur cette fraction de x bits; une
seule exprience de Bernouilli sera faire dans ce cas, chaque bit, pour dterminer sil est
erron ou pas.

Universit Paris-Est
Le modle Optimis de simulation (Optimized Simulation Model) a t propos dans un

second temps: dans ce modle on ne considre plus lerreur bit, mais lerreur paquet. Un paquet
de bits est considr erron si au moins lun de ses bits est erron ; connaissant la probabilit
derreur bit et la taille du paquet en bits, on pourra en conclure la probabilit derreur du paquet
selon la formule: PER= 1-(1-BER)t, o t est la taille du paquet en bits. Il suffira alors de faire
une seule exprience de Bernoulli chaque paquet pour dterminer sil est erron ou pas et la
transition dtat est suppose avoir lieu chaque x bits tel que x suit une loi gomtrique.
Cependant, J. Ebert et A. Willig dans leurs simulations faites [23] travaillent sur une valeur du
BER qui ninduit pas un PER de 100% dans le mauvais tat du canal cest--dire mme dans le
mauvais tat on peut toujours avoir des paquets non errons et donc qui aboutissent au
destinataire. Un modle simplifi de Gilbert-Elliot consiste considrer que ltat du canal
bascule de ltat bon ltat mauvais ds quun paquet est dtect perdu [54]; en dautres
termes, le PER est de 100% dans ltat mauvais du canal (tous les paquets sont errons), et tous
les paquets envoys dans le bon tat sont intacts et aboutissent alors au destinataire [55].
3.4 Protocoles utiliss dans RAMPE/INFOMOVILLE

Lapplication RAMPE/INFOMOVILLE consiste en un change de trames entre la borne
constitue d'un point d'accs et d'un Serveur de base de donnes dune part, et le PDA port par
l'aveugle dautre part. Ces trames changes sont actuellement dfinies selon trois catgories
utilisant chacune un certain protocole de communication:
Trame U (Utilisateur) toujours envoye depuis un PDA vers la borne. Cette trame
est utilise lorsque lutilisateur souhaite faire sonner la borne et sy diriger. Le
protocole utilis est TCP.
Trame R (Rafrachissement) toujours envoye depuis la borne vers un ou plusieurs

PDA. Cette trame est produite en cas de variation dhoraires ou dvnement
exceptionnel sur une ligne. Ces changements sont reflts dans la base XML que le
PDA doit tlcharger (rafrachir) ds rception de la trame R. Le protocole utilis est
UDP en mode broadcast.
Une trame V (Vhicule) est un message urgent, toujours envoy depuis la borne
vers un ou plusieurs PDA. Cette trame est produite lorsquun bus est lapproche de
larrt. Un message texte est contenu dans la trame V, immdiatement synthtis par
le PDA et que lutilisateur doit acquitter. Le protocole utilis est UDP en mode
broadcast.
Rcapitulons dans le tableau 7 suivant :

Universit Paris-Est
Trame Protocole Type Point PDA

dAccs
Trame Utilisateur U TCP Unicast/ Serveur Client
avec connexion
Tlchargement de la base de HTTP Unicast/ Serveur Client
donnes avec connexion
Trames urgentes R et V- UDP Broadcast/ Client Serveur
Rafrachissement et Vhicule Sans connexion
(appeles dans la suite Trames
de Service)
Table 7 Les trames RAMPE/INFOMOVILLE
3.5 Transmission point--multipoint

Dans les protocoles de communication, la transmission de donnes peut se faire en lun
des trois modes de diffusion suivants :
- Point Point (unicast): dans ce mode, un noeud metteur transmet des donnes un autre
nud rcepteur.
- Point Multipoint: qui se divise en deux sous-catgories : Multicast o un nud metteur

envoie des donnes un groupe de nuds rcepteurs, et broadcast o le nud metteur envoie
des donnes tous les nuds se trouvant sur le mme rseau.
Plusieurs applications ncessitent un transfert de point--multipoint pour diffuser une

information intressante un groupe ou tous les nuds du rseau, signaux dalarmes, trames
indiquantes dune congestion, une collision, etc.
TCP est un protocole orient connexion de la couche transport du modle OSI. TCP ne
peut pas tre utilis en broadcast. A cause des acquittements multiples, la connexion peut
souffrir d'un dlai et dun retard intolrables. UDP est un protocole non orient connexion de la
couche transport. Il nexige aucun acquittement, et peut donc tre utilis en mode broadcast.
Dans les rseaux filaires, et au niveau de la couche liaison de donnes (notamment la couche
802.3 adoptant le CSMA-CD), des paquets en unicast, en multicast ou en broadcast peuvent tre
retransmises en cas dune dtection de collision. Donc en quelque sorte la couche 2 ajoute une
certaine fiabilit UDP. On note quand mme des inconvnients: la retransmission des paquets
se fera aussi en mode broadcast et donc les rcepteurs ayant reu le paquet en premier lieu, vont
de mme recevoir sa retransmission.
Dans les rseaux locaux sans fil 802.11, un paquet unicast sera retransmis en cas de collision ou
de perte (un acquittement ne sera pas reu par lmetteur) ; mais des paquets en broadcast ne
peuvent pas tre dtects perdus car la technique de dtection de collision des rseaux filaires ne
peut pas tre utilise dans les rseaux 802.11 qui adoptent la technique CSMA/CA [20] et aussi
il ny a pas dacquittements en mode broadcast et donc il ny a pas de retransmissions.
Plusieurs propositions de protocoles ont t faites pour fiabiliser et rendre extensible une
transmission en multicast/broadcast : protocole Scalable Reliable Multicast (SRM) [26], Real-

Universit Paris-Est
Time Stream Transport Protocol Multicast (RSTP Multicast) [25]. Des propositions ont t de
mme faites pour les rseaux sans fil pour fiabiliser une transmission en broadcast : Redundant
Transmission Protocol (RT) [20], Real-Time Transport Protocol (RTP) [173], etc.
3.6 Protocole RAP

On propose dans ce chapitre un protocole de communication appropri au type de trafic
de donnes que nous rencontrons dans l'application RAMPE/INFOMOVILLE, spcifiquement
pour la transmission des messages urgents depuis la borne vers le PDA port par la PAM; ces
messages urgents (informations temps rel) sont transmis en mode broadcast par le protocole
UDP vers tous les PDAs associs la borne, et donc aucune garantie de livraison nest assure.
On introduit un protocole au niveau des couches suprieures du modle OSI (couche session)
pour fiabiliser les transmissions en mode broadcast.
Le protocole propos, nomm RAP pour RAMPE/INFOMOVILLE Application Protocol, offrira

un certain degr de fiabilit pour les transmissions sans fil comme le 802.11 (b/g) ; le but de
RAP est de minimiser les pertes de paquets ; il cherche fiabiliser le protocole UDP utilis en
mode broadcast. RAP sera encapsul dans des paquets UDP et introduira une redondance
priodique qui permettra de sonder et dvaluer le canal au-dessus de ce protocole; la
redondance sera introduite par une rptition des trames d'une manire spcifique, et le sondage
du canal par une encapsulation des donnes de gestion dans les paquets UDP ; cette gestion
permettra d'estimer les pertes de paquets et donc la fiabilit du rseau. Ceci permettra au
rcepteur (le PDA qui est en train de recevoir les messages urgents) dlaborer un indicateur de
la qualit du lien sans fil qui le relie au point daccs, lui permettant de fournir lutilisateur un
niveau de confiance dans lutilisation de son systme dinformation.
3.6.1 Mcanisme de fonctionnement de RAP

RAP introduit une redondance au-dessus du protocole UDP afin de minimiser les pertes
de paquets. Le mcanisme de fonctionnement du protocole RAP est le suivant: il y a au moins
une trame de donnes N (paquet UDP) chaque T secondes, et ce paquet sera retransmis n fois
(n=3 dans la figure 24) toutes les tr secondes.
Une tude et un protocole similaire RAP est propos par D. Maniezzo, M. Cesana, P.
Bergamo, M. Gerla et K. Yao et est appel RT Protocol (pour Redundant Transmission) [20]; le
but tait de fiabiliser une transmission de type streaming en multicast de donnes temps-rel sur
un canal radio WiFi; RT proposait une redondance au niveau des fragments de donnes ; les
fragments envoys dans un premier paquet seront rpts dans le paquet suivant selon un
mcanisme de sliding window ; de cette faon le rcepteur pourra toujours reconstituer les
donnes dun paquet perdu. RAP cherche par contre introduire une redondance au niveau des
paquets transmis, le trafic considr (les messages urgents envoys depuis la borne de la
station de bus vers les PDAs associs) ntant pas du type streaming.

Universit Paris-Est
Figure 24- Format du trafic dans le protocol RAP propos
Le trafic de donnes broadcast de RAMPE/INFOMOVILLE est principalement form de trames

trs courtes de quelques dizaines doctets (moins d'un MTU d'Ethernet, 1518 octets - Maximum
Transmission Unit qui est la grandeur maximale dune trame sur un rseau).
3.6.2 RAP- protocole de la couche Session

Le protocole RAP tourne audessus du protocole UDP et sera donc encapsul dans des
paquets UDP. RAP sera considr alors comme un protocole de la couche session du modle
OSI.
La couche RAP de lAP va recevoir de la couche applicative les trames Urgentes (R et V)

(trames de Service) chaque T secondes. Chaque trame sera envoye n fois par la couche session
et chaque copie de trame sera encapsule dans des paquets UDP. Au bout dun temps T
secondes, si une trame de Service nest pas reue de la couche applicative, la couche RAP de
lAP enverra une trame de Bourrage. Cette trame de bourrage servira maintenir le sondage de
canal pour les diffrents PDAs.
La trame de service et la trame de bourrage seront traites de la mme manire: elles seront
envoyes en n copies au Serveur.
Comme les trames (figure 25) sont numrotes et dates, contenant des champs indiquant les
dates de la trame courante, de la trame prcdente et de la trame suivante, le PDA, averti du
nombre de rptitions n, pourra estimer et compter les pertes et avoir par suite une ide sur ltat
du canal.
En rsum (tableau 8), les diffrentes trames changes lors dune communication Client-
Serveur utilisant le protocole RAP sont:
Trame Protocole Point dAccs PDA

Trame de Service (trames de RAP/UDP Client Serveur
rafrachissement R et Vhicule V
prcdemment nommes trames
urgentes)
Trame de Bourrage RAP/UDP Client Serveur
Table 8- Les catgories des trames RAP

Universit Paris-Est
3.6.3 Format de la trame de Service RAP
Figure 25- Format de la trame de Service RAP
La trame de service est constitue des champs suivants (figure 25):
- TYPE (1 octet): nombre indiquant le type de la trame de Service (0x01: R, 0x03: V par
exemple...).
- NUMERO de RPTITION (1 octet): indique le numro de la trame dans le slot de

rptition. Il doit tre plus petit ou gal au NOMBRE de RPTITION.
- JOUR, MOIS, ANNE de la trame courante (3 octets): indique la date de la trame transmise.
- HEURE, MINUTES, SECONDES de la trame courante (3 octets): indique le temps de la
trame transmise.
- NUMERO de TRAME (2 octets): donne un numro unique une trame. Ce numro pourrait
tre entre 0 et 64535.
- NOMBRE de RPTITION (1 octet): donne le nombre maximum de rptitions.
- INTERVALLE de RPTITION (1 octet): en secondes; cest le temps tr estim entre 2

rptitions.
- JOUR, MOIS, ANNE de la trame prcdente (3 octets) et HEURE, MINUTES,

SECONDES (3 octets): pourrait aider la gestion et peut tre aussi utilis pour certaines
statistiques.
- JOUR, MOIS, ANNE (3 octets) et HEURE, MINUTES, SECONDES (3 octets) de la trame

suivante: donne la date maximum de la prochaine nouvelle trame.
- DONNES (le nombre des octets est gal au MTU sans l'en-tte): ce champs dpend du type
de la trame.

Universit Paris-Est
3.6.4 Trame de Bourrage

La trame de Bourrage a une double fonctionnalit: dune part elle servira synchroniser
le lAP aux diffrents PDAs, en les informant de la date courante de lAP, du temps prvu pour
recevoir la trame suivante (soit une trame de service soit une trame de bourrage) et de la date de
la trame prcdente, et dautre part elle jouera un rle similaire une trame balise au niveau
MAC ou WiFi : prenons le cas o un PDA ne reoit aucune des trames de Service rptes.
Dans ce cas il ne va pas distinguer si la trame de Service ne lui a pas abouti ou si aucune trame
de Service na t envoye par le client en premier lieu. Il ne peut pas non plus savoir si le lien
est bon ou non. Avec la trame de bourrage, le PDA pourra savoir quil va recevoir au moins
cette trame de bourrage de la part de lAP au bout dun temps T. Sil ne reoit rien, dans ce cas
il va constater que le lien est mauvais: Le PDA sort par exemple de la zone de couverture de
lAP. Cest le cas le plus pire et cest alors la couche MAC qui va remdier cette situation et
envoyer une trame de dsassociation au PDA.
Dautre part si le PDA reoit une trame de bourrage mais ne reoit pas une trame de service
envoye avant cette trame de bourrage, le champ Numro de trame de la trame de bourrage,
qui correspond au numro de la dernire trame de Service qui a t envoye permettra au PDA
de savoir sil a bien reu cette trame ou non.
Le format de la trame de bourrage est identique celui de la trame de service hormis que la
trame de bourrage ne contient pas un champ "donnes". Le champ TYPE de valeur 0x05 indique
une trame de bourrage, et le champ "Numro de trame urgente" indique le numro de la dernire
trame urgente qui a t envoye.
3.6.5 Trame de Statistique

Dans le cas o on autorise le PDA transmettre des donnes vers le point daccs, on
peut imaginer quune trame de Statistique est envoye par le serveur (le PDA) vers le client (le
point daccs) dans laquelle il donne le nombre de trames (ou de rptitions) quil a bien reues.
Pour une transmission fiable, cette trame de statistique peut tre envoye en utilisant le protocole
TCP. Cette trame servira alors donner des informations sur ltat du canal en fonction
desquelles lAP pourra diminuer ou augmenter le nombre de rptitions dune trame. Si par
exemple la trame de statistique est envoye suite la rception de chaque trame urgente, lAP
calculera le rapport nombre de trames rptes reues par le PDA sur le nombre n de rptitions.
Cependant, lenvoie de cette trame de statistique par le PDA va lui faire consommer de lnergie
car il sera en tat actif ; cest pour cela, on peut proposer davoir une trame de statistique
envoye priodiquement ou chaque changement de ltat du lien de communication entre AP
et PDA.
Dautre part, le protocole RAP du PDA va aussi envoyer une trame de statistique sa couche
applicative. Cette trame servira calculer les paramtres du modle du canal et laborer un
degr de confiance pour lutilisateur ; elle servira comme un indicateur de qualit de la liaison
WiFi (le PDA est bien connect la borne, le canal est dune mauvaise qualit avec beaucoup de
pertes, ...etc).

Universit Paris-Est
Figure 26- Format de la trame de Statistique RAP
Les diffrents champs qui constituent une trame de Statistique sont:
- TYPE (1 octet): nombre indiquant que la trame est une trame de Statistique (0x04).
- NUMERO de RPTITION (1 octet): indique le nombre des rptitions reues.
- Numro de trame (2 octets): indique le numro de la dernire trame urgente reue.
- Nombre de RPTITION (1 octet): indique le nombre de rptitions n.
3.6.6 Autres problmes et remdes

Au-del du problme des pertes de paquets, le protocole RAP peut permettre de grer
dautre type de situation.
Un cas pouvant se prsenter o la borne diffuse une trame urgente puis un nouveau PDA
se connecte cette borne tandis que le message urgent est toujours valide (accident, bus
lapproche, panne sur une ligne, changement dhoraire, etc), ce message est alors rediffus.
Un PDA recevant alors une trame avec un numro identique celui dune trame reue
prcdemment, va simplement lignorer. Mais sil reoit une trame avec un numro suprieur
celui dune trame reue prcdemment, il la traitera et ce message sera synthtis vocalement et
nonc la PAM.
On peut toujours imaginer une autre solution dans laquelle le PDA lui-mme, aprs son
association une borne, demande la rediffusion de toutes les informations urgentes encore
valides. Mais ceci peut consommer de son nergie, exactement comme la redemande de sonnerie
envoye depuis le PDA vers la borne afin de reprer sa position.
3.7 Simulation et valuation de RAP
3.7.1 Simulation sur un canal rel

Pour tudier le fonctionnement dun protocole de communication et dterminer sa
fiabilit ou ses performances, il faut pouvoir le simuler sur un canal rel afin dobserver son
comportement surtout vis vis dventuelles perturbations que le canal peut introduire.
Dans ce paragraphe on prsente la simulation du protocole RAP propos et on compare

ses performances vis--vis de celles des autres protocoles utiliss dans la version actuelle de
RAMPE/INFOMOVILLE notamment le protocole UDP. Le logiciel OMNeT++ est utilis pour
cette simulation. Il permet dinclure dans la simulation des dispositifs rels ("Hardware-in-the-

Universit Paris-Est
loop"): deux composants dOMNeT++ peuvent alors communiquer entre eux travers un canal
rel; la classe d'OMNeT++ qui permet de faire cette communication est la classe "cScheduler"
dont les mhodes ou fonctions peuvent tre modifies selon lapplication. Le comportement des
deux protocoles RAP et UDP vis--vis les pertes pourront donc tre analyss sur un canal rel et
leurs fiabilits respectives compares.
Le modle de RAP tant un modle Client-Serveur, le client sera implant sur un

ordinateur, le serveur sur un autre ; ces deux ordinateurs communiqueront par la suite travers
une liaison WiFi.
Pour simuler le protocole UDP, le Client et le Serveur sont composs dune seule couche de
transport (ce sont deux modules simples dOMNeT++), tandis que pour RAP, on intgre une
couche Session qui implmentera le protocole RAP (client et serveur seront deux modules
composites dOMNeT++).
Pour pouvoir simuler une application en temps rel, le modle NED dOMNeT++ est le suivant:
un module client (cf. figure 27) gnrant les messages (UDP ou RAP) est connect, travers
un module cloud (pouvant jouer, dans des simulations ultrieures, le rle dun canal WiFi
modlis) linterface extClient qui le relie au serveur tournant sur un PC distant travers le
lien WiFi. Le serveur recevant les messages du client prsente une interface externe (aussi
appele extClient sur la figure 27) relie, travers un module cloud, au module server.
Les modules client et serveur implmentent tous les deux le protocole RAP.
Le trajet des messages envoys depuis le client au serveur est le suivant: [client cloud
extClient (interface vers le serveur externe)] [Connexion relle WiFi] [extClient (interface
vers client externe) cloud server].
Figure 27- Modle NED Client- Serveur de simulation sur un canal rel
3.7.1.1 Exprimentation
Lobjectif de lexprimentation est dillustrer par une plateforme de simulation la

capacit du protocole RAP fiabiliser une communication rseau sans fil et fournir un indice
de confiance lapplicatif RAMPE/INFOMOVILLE.

Universit Paris-Est
3.7.1.2 Elments de lexprimentation
Outils/Logiciels utiliss
- Wireshark : logiciel de capture de trames et danalyse de protocole rseau, qui permet de

capturer et danalyser les trames arrivant sur les adapteurs et les cartes rseaux dun
dispositif de communication [170].
- Iperf : logiciel en ligne de commande, qui permet de gnrer du trafic UDP ou TCP, de
mesurer la bande passante disponible entre le client et le serveur, etc [169].
- OMNeT++: outil de simulation libre d'vnements discrets conu pour simuler des rseaux
informatiques, des multiprocesseurs et d'autres systmes rpartis (cf. paragraphe 4 du
chapitre 1). Il permet aussi de faire des simulations temps rel [21].
Equipements utiliss
Quatre ordinateurs portables ayant les spcifications ci-dessous sont utiliss dans cette
manipulation:
Nom Matriel Systme Processeur Carte WiFi

dexploitation
Portable 1 Toshiba Windows XP Intel Pentium Intel Pro/Wireless LAN
Satellite M, 1.4Ghz 2100 3B Mini PCI
Adapter. Chipset: Intel
2100
Portable 2 DELL Latitude Windows XP Intel Pentium Intel Pro/Wireless 2200
M, 1.6Ghz BG Network
Connection. Chipset:
Calexico 802.11bg
MiniPCI RoW
Portable 3 IBM Lenovo Windows XP Intel Pentium Intel Pro/Wireless
M, 2.4Ghz 3945ABG Mini-PCI
Express Adapter.
Chipset: Intel
WM3945AG
Portable 4 HP Windows XP Intel Pentium Intel Pro/Wireless 2200
M, 2.4Ghz BG Network
Connection. Chipset:
Calexico 802.11bg
MiniPCI RoW.
Table 9- Spcifications du matriel de la manipulation
Infrastructure de lexprimentation
Les portables 1 et 2, distants de 3.5 mtres, forment un rseau ad-hoc RAMPEManip

802.11b sur le canal 10. Wireshark, iperf et OMNeT++ sont installs sur les deux portables
et une adresse rseau (IP pour Internet Protocol) manuelle est attribue chacun:

Universit Paris-Est
Portable 1 : 10.10.0.1
Portable 2 : 10.10.0.2
Sur le portable 1 tourne le Serveur OMNeT++ (cf. 3.7.1), qui communique, travers le
rseau sans fil RAMPEManip avec le Client OMNeT++ install sur le portable 2;
Client et Serveur vont changer des trames travers le canal radio WiFi. Iperf permet de
mesurer la bande disponible entre ces 2 portables et Wireshark de capturer toutes les trames
sortantes du Client et aboutissantes au Serveur.
Les portables 3 et 4 forment un rseau ad-hoc IperfManip 802.11b sur le canal 11. La
distance entre eux est de 4 mtres et iperf est install sur les deux.
Portable 3 : 192.168.0.1
Portable 4 : 192.168.0.2
Iperf permet de gnrer du trafic sur le rseau sans fil IperfManip, oprant sur le canal 11
et donc crer des interfrences sur le canal 10 utilis par le rseau RAMPEManip. Ceci
va permettre danalyser le comportement du protocole RAP vis--vis ces interfrences et
comparer alors sa fiabilit celle du protocole UDP.
Figure 28- Infrastructure de lexprimentation
Les commandes iperf
Les commandes iperf utilises dans lexprimentation sont les suivantes :
Gnration dun trafic TCP entre 2 machines (un serveur S et un client C)
Sur la machine S: # iperf -s

Sur la machine C: # iperf -c adresse IP Serveur

Universit Paris-Est
Le test dure par dfaut 10 secondes et utilise le protocole TCP sur le port 5001. Les mmes
commandes et le mme protocole sont utiliss pour mesurer la bande passante disponible entre 2
machines.
Gnration dun trafic UDP entre S et C
Sur la machine S: # iperf -s -u

Sur la machine C: # iperf -c adresse IP Serveur -u
Loption u dsigne du trafic UDP. La bande passante par dfaut est 1 Megabits par seconde.
Le test dure par dfaut 10 secondes.
Pour choisir le dbit on utilise loption -b et on spcifie les lettres suivantes avec la valeur du
dbit:
b: bits par seconde
k: kilobits par seconde
m: megabits par seconde
g: gigabits parseconde
Pour un dbit en octets par seconde, on utilise ces mmes lettres en majuscule.

Sur la machine C: # iperf -c adresse IP Serveur -u -b 5m
Gnrer un dbit entre C et S pendant 10 heures
On utilise loption -t et on la fait suivre par la dure dsire en secondes.

Sur la machine C: # iperf -c adresse IP Serveur -u -b 5m -t 36000 (trafic gnr pendant
10 heures)
Avec loption i on peut avoir un rapport intermdiaire toutes les x secondes (x est spcifi
aprs loption i):

Sur la machine C: # iperf -c adresse IP Serveur -u -b 5m -t 3600 i 1 (le rapport est gnr
chaque seconde).
3.7.1.2.1 Tests raliss
1- Qualit des liens- protocole TCP
Avant de commencer tester les protocoles UDP et RAP, les liaisons entre les portables 1 et 2 et
les portables 3 et 4 sont testes ; on vrifie aussi le partage de la bande passante lors dune
transmission simultane sur ces deux liens interfrents en utilisant iperf:

Universit Paris-Est
Entre les portables 1 et 2:
Portable1: iperf Server: > iperf s i 1 (serveur dmarr en mode TCP et rapport intermdiaire
demand chaque seconde)
Portable2: iperf Client : > iperf c 10.10.0.1 i 1 t 60 (trafic TCP gnr pendant 60 secondes)
Sur le Portable2 on observe:

C:\Documents and Settings\jsayah\Desktop>iperf -c 10.10.0.1 -i 1 -t 60
------------------------------------------------------------
Client connecting to 10.10.0.1, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[1912] local 10.10.0.2 port 1045 connected with 10.10.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[1912] 0.0- 1.0 sec 632 KBytes 5.18 Mbits/sec
[1912] 9.0-10.0 sec 672 KBytes 5.51 Mbits/sec
La bande passante entre les 2 portables est aux alentours des 5 Mbits/s ; les deux portables
fonctionnent en 802.11b ; la bande passante thorique pour les donnes utilisateurs au niveau de
la couche MAC est de 11 Mbits/s mais elle est de 5 6 Mbits/s linterface entre la couche
PHY et linterface air [24] (cf. paragraphe 2.2.3.6).
Entre les portables 3 et 4:
Portable3: iperf Server: > iperf s i 1 (serveur dmarr en mode TCP et rapport intermdiaire
demand chaque seconde)
Portable4: iperf Client: > iperf c 192.168.0.1 i 1 t 60 (trafic TCP gnr pendant 60
secondes)
De mme le dbit utile est aux alentours de 5Mbits/s, les 2 interfaces WiFi fonctionnent en
802.11b sur le canal 11.
2- Partage de la bande passante
Maintenant on dmarre les deux gnrateurs de trafic iperf : sur le canal 10 (sur les portables 1 et
2) en TCP puis aprs un dlai de 10 secondes sur le canal 11 (sur les portables 3 et 4).

Universit Paris-Est
On observe sur le Portable2 une chute de la bande passante linstant 10s. Le canal 10 et le
canal 11 tant adjacents, ceci explique ce partage de bande. Quand le trafic sarrte sur le canal
11 ( linstant 23 secondes de lexemple suivant), le canal 10 bnficiera de nouveau de toute la
bande.
C:\Documents and Settings\jsayah\Desktop>iperf -c 10.10.0.1 -i 1 -t 60

------------------------------------------------------------
Client connecting to 10.10.0.1, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
3- Qualit des liens- protocole UDP
Reprenons la mme exprimentation avec un trafic UDP.
Entre les Portables 1 et 2:
Sur le rseau RAMPEManip- Canal 10:

Portable1: iperf Server: > iperf s u i 1 (serveur dmarr en UDP)
Portable2: iperf Client: > iperf c 10.10.0.1 u b 1m i 1 t 60 (trafic UDP gnr un dbit de
1Mbits/s pendant 60 secondes)
On a bien le dbit de 1Mbits/s entre le client et le serveur.

Avec loption 5m, on obtient 5Mbits/s au niveau de la bande.
Avec loption 10m, le dbit reste 5 Mbits/s. Donc quand le trafic gnr dpasse la bande
disponible au niveau de la liaison 802.11b, cette bande est maintenue sa valeur pratique
maximale.

Universit Paris-Est
Entre les Portables 3 et 4:
Sur le rseau IperfManip- Canal 11:

Portable3: iperf Server: > iperf s u i 1 (serveur dmarr en UDP)
Portable4: iperf Client: > iperf c 192.168.0.1 u b 1m i 1 t 60 (trafic UDP gnr avec 1
Mbps)
On a bien le dbit de 1Mbits/s au niveau de la bande passante entre le client et le serveur.

Avec loption 5m, on a aussi du 5Mbits/s au niveau de la bande.
Avec loption 10m, le dbit reste 5 Mbits/s. Donc quand le trafic gnr dpasse la bande
disponible au niveau de la liaison 802.11b, cette bande est maintenue sa valeur pratique
maximale.
C:\Documents and Settings\jsayah\Desktop>iperf -c 10.10.0.1 -u -b 5m -i 1

-t 60s
------------------------------------------------------------
Client connecting to 10.10.0.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 8.00 KByte (default)
------------------------------------------------------------
C:\Documents and Settings\uobadmin\Desktop>iperf -c 192.168.0.1 -u -b 5m -i 1

-t 60s
------------------------------------------------------------
------------------------------------------------------------
------------------------------------------------------------
On dmarre iperf sur IperfManip linstant 10s et on observe bien la partage de la bande:

Universit Paris-Est
C:\Documents and Settings\jsayah\Desktop>iperf -c 10.10.0.1 -u -b 5m -i 1
-t 60s
------------------------------------------------------------
------------------------------------------------------------
------------------------------------------------------------
Ces tests ont montr que le comportement du lien WiFi est normal: la dbit pratique de 802.11b
est infrieur au dbit thorique, le partage de la bande entre deux canaux adjacents interfrents
est vrifi On passe dans ce qui suit la simulation des protocoles UDP et RAP sur les
rseaux et canaux rels tablis.
3.7.1.3 Simulation des protocoles RAP et UDP
Dans ce paragraphe, on dcrit la simulation et on compare le fonctionnement des deux

protocoles UDP et RAP sur les rseaux ad-hoc tests et configurs du paragraphe prcdent. Le
but est de montrer lefficacit du protocole RAP par rapport au protocole UDP; en dautres
termes, on dmontre comment RAP ajoute une certaine fiabilit par rapport UDP sur un canal
WiFi rel. Pour ce faire, on essaye davoir un canal WiFi perturb et on analyse le
comportement des deux protocoles sur ce mme canal.
Le taux de pertes paquets (PER pour Packet Error Rate) est considr comme la mtrique
indicatrice de la qualit du lien. Un certain nombre de paquets est gnr et on calcule pour
chaque protocole (aprs avoir compt les paquets perdus), le PER.
UDP et RAP fonctionnent en mode Client-Serveur. On utilise pour ceci le rseau ad-hoc
RAMPEManip entre les portables 1 et 2. Le client (UDP ou RAP) (portable 2) communique
avec le Serveur (portable 1), tous les deux simuls sur OMNeT++, travers une liaison WiFi
relle.
3.7.1.3.1 Simulation du Protocole UDP
Sur le rseau ad-hoc RAMPEManip tourne maintenant la simulation sur OMNeT++

dcrite dans le paragraphe 3.7.1 du protocole UDP en mode Client- Serveur (Portable 1: Serveur
et Portable 2: Client).

Universit Paris-Est
Donnes de la simulation
- Les paquets gnrs par le client OMNeT++ sont numrots (1, 2, 3, etc).
- Le serveur OMNeT++ recevant les paquets du Client compte les pertes. A chaque fois il
compare le numro du paquet quil est suppos recevoir au numro du paquet reu et sil
trouve une diffrence, il compte le nombre de paquets perdus et incrmente un compteur.
Il enregistre dans un fichier XML, ltat de chaque paquet: un paquet qui a abouti au
serveur est not vrai et un paquet perdu est not faux (se sont les donnes brut de
la simulation, nous permettant plus tard den retirer les diffrents paramtres pour une
modlisation du canal rel).
- Frquence de gnration des paquets : 1 paquet chaque 1 seconde.
- Longueur du Paquet : 20 octets : le message gnr par la couche applicative contient
une partie fixe de 20 octets et une partie de bourrage variable. La partie fixe est de 20
octets, puis on fait varier la longueur de la partie variable.
On prsente dans les paragraphes suivants les rsultats obtenus pour un petit nombre de paquets
UDP gnrs par le Client (500 paquets) et ceci pour un test de validation rapide du canal
(vrifier le scnario qui peut prsenter le plus de pertes), puis on gnralise et on rcapitule les
rsultats pour un grand nombre de paquets gnrs, permettant une meilleure tude statistique.
Scnarios de simulation
Sans trafic gnr sur le rseau IperfManip
On commence notre manipulation sans gnrer du trafic sur le rseau IperfManip adjacent.
1- 500 messages UDP gnrs par le client 0 messages perdus.
2- Portable 2 loign du portable 1 et toujours en ligne de vue (mais en espace ferm) :

- Distance lorigine: 3.5m ; Distance actuelle: 10 m.
500 messages UDP gnrs par le client 9 messages perdus
3- Portable 2 toujours loign du portable 1.

- Frquence des paquets : 1 paquet chaque 0.001s.
500 messages UDP gnrs par le client 10 messages perdus
4- Portable 2 loign du portable 1 (Distance: 10 m) mais cette fois les 2 portables ne sont plus
en ligne de vue (mais toujours en espace ferm).
- Longueur du paquet : 120 octets
500 messages gnrs par le client 47 messages perdus
Avec trafic gnr sur le rseau IperfManip
Un trafic UDP est maintenant gnr avec iperf sur les deux portables 3 et 4 sur le canal 11 avec
un dbit de 5Mbits/s.

Universit Paris-Est
1- 500 messages UDP gnrs par le client 2 messages perdus
2- Portable 2 loign du portable 1 et toujours en ligne de vue (mais en espace ferm).

- Distance lorigine: 3.5m ; Distance actuelle: 10 m.

4- Portable 2 loign du portable 1 (distance: 10 m) mais cette fois les 2 portables ne sont plus
500 messages gnrs par le Client 118 messages perdus
3.7.1.3.2 Simulation du Protocole RAP
Les mmes tests ont t raliss avec le protocole RAP simul sur OMNeT++ :
Donnes de la simulation
- RAP tourne dans la couche session et envoie le message reu de la couche applicative n
fois (n tant le nombre maximal de rptitions c..d le nombre de copies de la trame. Au
dbut n=2).
- Le Serveur compte les pertes: un message est suppos perdu si les 2 copies ont t
perdues; les rptitions perdues sont aussi comptes. Il enregistre entre autres, dans un
fichier XML, ltat de chaque rptition: une rptition qui a abouti au serveur est note
vrai et une rptition perdue est note faux (se sont les donnes brut de la
simulation, nous permettant plus tard den retirer les diffrents paramtres pour une
modlisation du canal rel).
- Les paquets gnrs au niveau du simulateur OMNeT++ sont numrots de la faon
suivante: Numro de Rptition:Numro de Trame. Exemple : 1:1 (1re copie ou
rptition de la 1re trame) -2 :1 (deuxime rptition de la 1re trame) - 1:2 (1re rptition
de la 2me trame) - 2:2- etc.
- Frquence de gnration des paquets: 1 paquet chaque 1 seconde et chaque rptition
0.1 seconde.
On prsente dans les paragraphes suivants les rsultats obtenus avec un petit nombre de
paquets RAP gnrs par le Client (500 paquets), ceci pour un test de validation rapide du canal,
puis on gnralise et on rcapitule les rsultats pour un grand nombre de paquets gnrs, pour
permettre une tude statistique plus fiable.

Universit Paris-Est
Scnarios de simulation
Sans trafic gnr sur le rseau IperfManip
1- 500 messages RAP gnrs par le client (messages rpts sont au nombre de 1000) 0
messages perdus, 0 rptitions perdues
2- Portable 2 loign du portable 1 et toujours en ligne de vue.
- Distance lorigine : 3.5m et distance actuelle : 10 m.
500 messages RAP gnrs par le client 2 messages perdus, 15 rptitions perdues (on
remarque sur Wireshark et aussi sur OMNeT++ que parfois quelques rptitions sont perdues
mais dautres non ce qui fait que le serveur reoit au moins un exemplaire du message envoy et
donc le message nest pas considr perdu).

- Frquence des paquets : 1 paquet chaque 0.001s avec frquence de rptition tr =
0.0001s.
500 messages gnrs par le client 2 messages perdus, 17 rptitions perdues.
4- Portable 2 loign du portable 1 (distance: 10 m) mais cette fois les 2 portables ne sont plus
0.0001s.
500 messages gnrs par le client 16 messages perdus, 86 rptitions perdues
Avec trafic gnr sur le rseau IperfManip
Du trafic UDP est maintenant gnr avec iperf sur les 2 portables 3 et 4 sur le canal 11 avec un
dbit de 5m.
1- 500 messages RAP gnrs par le client 1 message perdu, 4 rptitions perdues.
2- Portable 2 loign du portable 1 et toujours en ligne de vue.

- Distance lorigine : 3.5m et distance actuelle : 10 m.

0.0001s.
4- Portable 2 loign du portable 1 (Distance: 10 m) mais cette fois les 2 portables ne sont plus

Universit Paris-Est
500 messages gnrs par le client 34 messages perdus, 229 rptitions perdues
3.7.1.4 Tableau rcapitulatif comparatif (UDP vs. RAP sur un canal rel)
Daprs les scnarios tests dans le paragraphe prcdent, on remarque que le plus grand
nombre de paquets perdus a t observ pour le scnario 4 (dans le cas dUDP et de RAP). On
repart alors de ce scnario, et on gnre un plus grand nombre de paquets afin de pouvoir faire
une analyse des protocoles UDP et RAP et pouvoir comparer leur fiabilit. Plusieurs tests ont t
faits et sont rcapituls dans le tableau 10 ci-dessous.
Paramtres
- Taux de perte = nombre de messages perdus/nombre de messages gnrs

- D = Distance Client-Serveur. Par dfaut, D = 3.5 m.
- Tg = temps de gnration de messages: 1 message chaque Tg secondes. Par dfaut, Tg =
1s
- tr = temps de rptition en RAP : 1 rptition chaque tr secondes. Par dfaut, tr = 0.1s
- Lb = longueur variable du message gnr (b = bourrage). La longueur fixe tant de 20
octets. Par dfaut, Lb = 0
- n = nombre de rptitions des trames dans RAP. Par dfaut, n=2
- Diperf = Dbit gnr avec Iperf sur le rseau IperfManip canal 11. Il vaut 0 quand on na
pas de trafic gnr au niveau dIperfManip. Par dfaut, Diperf = 0
- Drampe=La bande passante (mesure avec iperf) disponible entre le Client et le Serveur
RAMPE au moment de la simulation
- V= ligne de vue (Oui ou Non). Par dfaut, V= Oui
On mentionne, chaque test, le paramtre chang avec sa valeur; les autres paramtres tant
maintenus leurs valeurs par dfaut (par exemple dans le test 2, on change les valeurs de Tg et tr
en mentionnant le dbit sur le rseau RampeManip; pour le test 6, on change les valeurs de Diperf
(un dbit est maintenant gnr au niveau du rseau IperfManip) tout en gardant les autres
paramtres leur valeur par dfaut), Les valeurs entre parenthses dsignent le nombre de
rptitions perdues: pour UDP, nombre de paquets = nombre de rptitions puisque un paquet
est envoy une fois, tandis que pour RAP, un paquet va tre rpt n fois.
N Manip Paramtres Taux de perte UDP Taux de perte RAP (1)

1 Drampe =5.2 Mb/s 0/500 0/500 (0/1000)
2 Tg = 0.001s 0/500 0/500 (0/1000)
tr = 0.0001s
Drampe = 5.2Mb/s
3 Tg = 0.001s 0/500 0/500 (0/1000)
tr = 0.0001s
Lb = 10 octets
Drampe = 5.2Mb/s
4 Tg = 0.001s 0/500 0/500 (0/1000)
tr = 0.0001s
Lb = 50 octets
Drampe = 5.2Mb/s
1
Nombre de rptitions perdues

Universit Paris-Est
5 Tg = 0.001s 0/500 0/500 (0/1000)

tr = 0.0001s
Lb = 100 octets
Drampe = 5.2Mb/s
6 Diperf = 2m 2/500 1/500 (3/1000)
Drampe = 2.9 Mb/s
7 Diperf = 4m 2/500 1/500 (3/1000)
Drampe = 2.85 Mb/s
8 Diperf =5m 2/500 1/500 (4/1000)
Drampe = 2.75 Mb/s
9 Tg = 0.001s 3/500 1/500 (5/1000)
tr = 0.0001s
Diperf =5m
Drampe = 2.75Mb/s
10 Tg = 0.001s 3/500 1/500 (5/1000)
tr = 0.0001s
Lb = 10 octets
Diperf =5m
Drampe = 2.75Mb/s
11 Tg = 0.001s 3/500 1/500 (5/1000)
tr = 0.0001s
Lb = 50 octets
Diperf =5m
Drampe = 2.75Mb/s
12 Tg = 0.001s 3/500 1/500 (5/1000)
tr = 0.0001s
Lb = 100 octets
Diperf =5m
Drampe = 2.75Mb/s
13 D = 10 m 9/500 2/500 (15/1000)
Drampe = 3.85Mb/s
14 D=10 m 10/500 2/500 (17/1000)
Tg =0.001s
tr = 0.0001s
Drampe = 3.85Mb/s
15 D = 10 m 10/500 2/500 (17/1000)
Tg =0.001s
tr = 0.0001s
Lb = 10 octets
Drampe = 3.85Mb/s
16 D = 10 m 10/500 2/500 (17/1000)
Tg =0.001s
tr = 0.0001s
Lb = 50 octets
Drampe = 3.8Mb/s

Universit Paris-Est
17 D = 10 m 10/500 2/500 (18/1000)

Tg =0.001s
tr = 0.0001s
Lb = 100 octets
Drampe = 3.8Mb/s
18 D = 10 m 47/500 16/500 (86/1000)
Tg = 0.001s
tr = 0.0001s
Lb = 100 octets
Drampe = 1.6Mb/s
V=Non
19 D = 10 m 54/500 5/500 (89/1000)
Diperf =5m
Drampe = 1.3Mb/s
20 D = 10 m 54/500 6/500 (91/1000)
Tg = 0.001s
tr = 0.0001s
Diperf =5m
Drampe = 1.3Mb/s
21 D = 10 m 54/500 6/500 (91/1000)
Tg = 0.001s
tr = 0.0001s
Lb = 10 octets
Diperf = 5m
Drampe = 1.3Mb/s
22 D = 10 m 54/500 6/500 (91/1000)
Tg = 0.001s
tr = 0.0001s
Lb = 50 octets
Diperf = 5m
Drampe = 1.3Mb/s
23 D = 10 m 56/500 6/500 (91/1000)
Tg = 0.001s
tr = 0.0001s
Lb = 100 octets
Diperf = 5m
Drampe = 1.3Mb/s
24 D = 10 m 118/500 34/500 (229/1000)
Tg = 0.001s
tr = 0.0001s
Lb = 100 octets
Diperf = 5m
Drampe = 0.8Mb/s
V = Non
25 D = 10 m 6642/30000 1997/30000 (13222/60000)
Tg = 0.001s
tr = 0.0001s
Lb = 100 octets
Diperf = 5m

Universit Paris-Est
Drampe = 0.8Mb/s
V = Non
n=2
26 D = 10 m 680/30000 (19415/90000)
Tg = 0.001s
tr = 0.0001s
Lb = 100 octets
Diperf = 5m
Drampe = 0.8Mb/s
V=Non
n=3
27 D = 10 m 171/30000 (28101/120000)
Tg = 0.001s
tr = 0.0001s
Lb = 100 octets
Diperf = 5m
Drampe = 0.8Mb/s
V=Non
n=4
28 D = 10 m 38/30000 (31090/150000)
Tg = 0.001s
tr = 0.0001s
Lb = 100 octets
Diperf = 5m
Drampe = 0.8Mb/s
V = Non
n=5
Table 10- Comparaison UDP et RAP (canal rel)
3.7.1.5 Interprtations et observations
Le client envoie des trames au serveur travers le canal radio rel (canal 10). La distance
lorigine entre client et serveur (portables 1 et 2) est de 3.5 mtres et sont disposs en ligne de
vue; aucun trafic sur le canal radio adjacent (canal 11) du rseau IperfManip nest gnr; le
canal 10 bnficie alors de toute la bande disponible (5.2 Mbps), et aucune perte de paquet nest
observe (lensemble des 500 paquets gnrs par le client aboutissent au serveur) (manip 1). On
obtient les mmes rsultats quand on augmente la frquence de gnration des messages (1
message chaque 0.001s, dans le cas de RAP on diminue le temps de rptition). Quand on
augmente la longueur du champ donnes (une partie de bourrage de longueur 10 octets est
ajoute, puis 50 octets et enfin 100 octets) (manip 2 5).
Des pertes commencent tre observes quand le canal 11 adjacent au canal 10 commence
interfrer avec ce dernier : du trafic est gnr avec iperf sur ce canal 11 (manip 6) et la bande
passante est alors partage entre les deux canaux. La bande passante disponible entre le client et
le serveur diminue (elle est aux alentours de 2.9 Mbps); 2 paquets parmi 500 naboutissent pas
au serveur. Pour RAP, chaquet paquet gnr est rpt 2 fois (n=2 au dbut) donc au total on a
1000 rptitions: 3 de ces rptitions naboutissent pas au serveur, deux dentres elles tant les
rptitions dun mme paquet et donc un paquet au total est perdu (un paquet est perdu si toutes

Universit Paris-Est
ses rptitions sont perdues). Pour les manipulations 7 12, on augmente le dbit du trafic
gnr ainsi que la longueur du paquet et on diminue le temps entre 2 paquets et entre deux
rptitions mais les pertes ne varient pas significativement par rapport la manip 6.
La distance entre client et serveur est maintenant de 10m (manip 13), la bande passante
disponible est aux alentours de 3.9 Mbps ; 9 paquets parmi 500 sont perdus en UDP pour 2
paquets en RAP (15 rptitions). Les mmes rsultats sont observs dans les manipulations 14
17 en diminuant Tg et tr et en augmentant la longueur des paquets gnrs.
Dans la manip 18, les deux portables ne sont plus en ligne de vue; un obstacle (un paravant en
fer forg) les sparait et 47 paquets sont perdus en UDP pour 16 en RAP (la bande disponible est
de 1.3 Mbps).
Revenons la ligne de vue et la distance de 10m entre client et serveur mais cette fois un trafic
est gnr sur le canal 11 (manip 19 23): aux alentours de 54 paquets perdus en UDP pour 6 en
RAP mme en modifiant Tg, tr et Lb.
Le plus grand nombre de paquets perdus est observ dans la manip 24: la distance entre client et
serveur est de 10m, ils ne sont pas en ligne de vue et un trafic est gnr sur le canal interfrent
(la bande passante est aux alentours de 0.8Mb/s): 118 paquets sont perdus en UDP pour 49
paquets en RAP (268 rptitions).
De l, le scnario 24 sera adopt pour une comparaison du protocole UDP avec le protrocole
RAP: un plus grand nombre de paquets sera gnr et envoys depuis le client vers le serveur :
30,000 paquets sont gnrs partir de la manip 25. Le nombre n de rptitions (pour RAP) est
ensuite augment dans les manipulations 26 28 (n = 3, 4 et 5 respectivement).
Pour comparer la fiabilit de RAP celle dUDP, on calcul le taux derreurs paquets (PER pour
Packet Error Rate), dans chacune des manipulations du tableau 10, pour les deux protocoles
(PER tant la mtrique indicatrice de la qualit du lien Wifi considre dans ces
exprimentations).
Prenons la manip numro 25: pour UDP, la probabilit de pertes est de 22,14% (6642 paquets
perdus parmi 30000 6642/30000 = 0,2214).
Pour RAP avec un nombre de rptitions de 2, la probabilit de perte est de 6,65%, qui est la
probabilit de perdre toutes les rptitions dun mme paquet (les 2 trames rptes)
(1997/30000 = 0,0665).
Ceci sexplique par le fait que la probabilit de perdre 2 trames UDP correspond la probabilit
conjointe de perdre la premire et la probabilit de perdre la seconde et est gale 0,22142=
4,9% (une probabilit de 6,65% est retrouve avec RAP pour n = 2).
Avec n = 3 pour RAP (manip 26), on a une probabilit de pertes de 2,26% (680 trames sur
30000 sont perdues): probabilit de perdre 3 trames UDP= (0,2214)3= 1,08% (qui est environ la
probabilit de perte de RAP).
Pour n=4 (manip 27), PER RAP= 0.57%, et PER RAP= 0.12% pour n=5 (manip 28).
On remarque logiquement que quand on augmente le nombre de rptitions, la probabilit de
pertes diminue.
Le protocole UDP est un protocole sans connexion et donc nest pas fiable pour des
conditions de transmissions difficiles. Le protocole RAP ajoute une certaine fiabilit au

Universit Paris-Est
protocole UDP, il ne ncessite aucun acquittement de la part du rcepteur et peut alors tre
utilis en mode broadcast.
3.7.2 Identification des paramtres du canal WiFi

Les protocoles UDP et RAP ont t simuls, dans le paragraphe 3.7.1, sur un canal radio
802.11 rel. Diffrents paramtres doivent tre identifis pour pouvoir modliser ce canal par un
modle de Gilbert-Elliot. La simulation des protocoles UDP et RAP sur un canal modlis
permettra dvaluer leurs performances et de comparer leurs fiabilits tout en ayant la flexibilit
de modifier les diffrents paramtres et tudier leurs impacts sur le fonctionnement des deux
protocoles.
Le paragraphe 3.3 prsente le modle de canal de Gilbert-Elliot et la mthode de

simulation Optimise propose par J. Ebert et A. Willig [23] (simulation au niveau paquet
dune communication radio). Ce modle considre deux tats du canal: Bon et Mauvais
et la dure de sjour dans un certain tat suit une loi gomtrique de paramtre p.
Cette mthode de simulation sera adopte dans nos simulations des protocoles UDP et RAP, et
on calcule tous les paramtres de ce canal de Gilbert-Elliot daprs les simulations faites sur le
canal rel.
Commenons par calculer la taille du paquet envoy depuis le client vers le serveur: les donnes
envoyes depuis la couche applicative du client vers le serveur sont de 120 octets (partie fixe +
partie de bourrage) (cas 24 du tableau 10); on ajoute cette longueur les 8 octets dentte UDP
et les 20 octets dentte IP; la longueur totale du paquet considr sera alors de 148 octets soit
1184 bits.
Pour le taux derreur binaire des deux tats du canal, et en considrant dans un premier temps le
modle simple de Gilbert-Elliot (tous les paquets envoys durant le mauvais tat sont perdus et
ceux envoys durant le bon tat aboutissent au destinataire), le taux derreur binaire du mauvais
tat (not BERm- cf. figure 23) sera alors de 0.05 (ceci impliquera un PERm de 1 daprs la
formule PER=1-(1-BERm)t, tel que t est la longueur du paquet en bits, soit 1184 bits) et le taux
derreur binaire du bon tat, not BERb sera gal 0 (impliquant un PER de 0).
Dautre part, dans le modle optimis de Gilbert-Elliot, les dures de sjour dans le bon et le
mauvais tat suivent une loi gomtrique de paramtre p. Ce paramtre peut tre calcul daprs
les histogrammes tracs partir des fichiers XML de la simulation sur canal rel (ces fichiers
XML contiennent les donnes brut de la simulation; ltat de chaque paquet ou rptition est
indiqu par faux si le paquet est perdu et par vrai sil a abouti) ; dans le cas du modle
simple de Gilbert-Elliot, ce paramtre p est calcule daprs les histogrammes des nombres de
paquets conscutifs sans erreurs (pour le bon tat) et le nombre de paquets conscutifs errons
(pour le mauvais tat);
Voici un extrait du fichier XML, de la simulation UDP sur canal rel :
<root>
<META>
Distance=10m (pas en ligne de vue), priode=0.001s, nombre de rptitions=1, longueur
totale du paquet avec bourrage: 148 octets
</META>
<NumPaquet n="1">
<NumRep n="1">

Universit Paris-Est
<Received>vrai</Received>
</NumRep>
</NumPaquet>
<NumPaquet n="2">
<NumRep n="1">
</NumRep>
</NumPaquet>
<NumPaquet n="3">
<NumRep n="1">
</NumRep>
</NumPaquet>
Pour RAP avec un nombre de rptitions de 3:
<root>
<META>
Distance=10m (pas en ligne de vue), priode=0.001s, nombre de rptitions=3, rythme
des rptitions=0.0001s, longueur totale du paquet avec bourrage: 148 octets
</META>
<NumPaquet n="1">
<NumRep n="1">
</NumRep>
<NumRep n="2">
</NumRep>
<NumRep n="3">
</NumRep>
</NumPaquet>
<NumPaquet n="2">
<NumRep n="1">
</NumRep>
<NumRep n="2">
</NumRep>
<NumRep n="3">
</NumRep>
</NumPaquet>
Les histogrammes sont tras avec le logiciel Matlab [171]. Un outil (toolbox) nomm
xml_toolbox prsent sous Matlab, permet danalyser des fichiers XML et den extraire les
donnes. Ceci permet de relever le nombre conscutifs de paquets vrai et le nombre
conscutifs de paquets faux et de les sauvegarder dans un fichier.
On montre dans la figure 29 suivante les histogrammes tras dans le cas du canal rel (laxe des
x dtermine le nombre de paquets conscutifs et laxe des y le nombre de fois que ce nombre
conscutif a t observ) pour les bons et les mauvais tats (les graphes de gauche concernent les
paquets conscutifs dans le bon tat et ceux de droite les paquets conscutifs errons du mauvais
tat), et ce pour les deux cas dUDP et RAP (avec un nombre n de rptitions gal 3):

Universit Paris-Est
1500 3500
UDP sur un canal rel 3000

UDP sur un canal rel
-Bon tat- -Mauvais tat-
2500
1000
2000
1500
500
1000
500
0 0
0 50 100 150 200 250 300 1 2 3 4 5 6 7 8 9 10
4500 10000
4000 9000
RAP n=3 sur un canal rel RAP n=3 sur un canal rel
-Bon tat- 8000 -Mauvais tat-
3500
7000
3000
6000
2500
5000
2000
4000
1500
3000
1000 2000
500 1000
0 0
0 50 100 150 200 250 300 1 2 3 4 5 6 7 8 9 10
un canal rel
Un nombre de paquets conscutifs reus sans erreurs plus grand que celui des paquets
conscutifs errons est toujours observ: par exemple (dans le cas dUDP), 265 paquets
conscutifs non errons ont t observs; en RAP (n = 3), 280 paquets ont t observs. Par
contre, dans UDP, on a un maximum de 7 paquets conscutifs errons pour 8 paquets
conscutifs errons dans RAP (n = 3).
Pour en dduire le paramtre p de la loi gomtrique, la fonction sous matlab gkdeb() est
utilise; elle permet, partir dun histogramme, de dterminer la moyenne et la variance dune
loi gomtrique. La moyenne dune loi gomtrique tant linverse de son paramtre p
(moyenne=1/p) do on peut en dduire p.
p0 = 0.00058213 pour le mauvais tat (le mauvais tat tant ltat0) et p1= 0.00016577 pour le
bon tat (le bon tat tant ltat1).
Rcapitulons les paramtres du modle de canal de Gilbert-Elliot (simplifi et optimis) calculs
daprs les simulations du canal rel par le schma de la figure 30 suivante:

Universit Paris-Est
Figure 30- Identification des paramtres du canal WiFi
Dans ce modle simple, et daprs les histogrammes des paquets conscutifs errons et des
paquets conscutifs sans erreur, les probabilits de transition du bon tat vers le mauvais tat
(Pbm) et vice versa (Pmb) sont gales 1: le canal reste dans le mauvais tat pendant X bits (qui
est la dure de sjour dans ce mauvais tat et qui suit une loi gomtrique de paramtre p0);
aprs ces X bits, il bascule directement au bon tat; de mme pour le bon tat qui bascule au
mauvais tat aprs X bits suivant une loi gomtrique de paramtre p1. Le canal ayant ces
paramtres est considr un canal de mauvaise qualit.
Dans un second temps, on considre le modle optimis de Gilbert-Elliot mais cette fois
en considrant les probabilits de transition dtat. En dautres termes, on considre un PER
diffrent de 1 dans le mauvais tat (les paquets envoys durant le mauvais tat ne sont pas tous
perdus), tandis quun PER de 0 est toujours considr pour le bon tat (tous les paquets envoys
durant le bon tat aboutissent leur destination). On value par ce scnario les protocoles UDP
et RAP pour diffrents types de canaux : canal de qualit moyenne et canal de bonne qualit
(celui de mauvaise qualit tant dj montr dans la figure 30).
Pour cela, et pour un canal de qualit moyenne, on considre un BER de 0 dans le bon tat et un
BER de 0.001 dans le mauvais tat (BER = 0.001 implique PER = 0.69; 69% des paquets
envoys durant le mauvais tat sont perdus).
Pour un canal de bon tat, on considre un BER de 0 dans le bon tat et un BER de 0.0005 dans
le mauvais tat (BER = 0.0005 implique PER = 0.44; 44% des paquets envoys durant le
mauvais tat sont perdus). Dans les deux cas du canal, p0 = 0.00058213 pour le mauvais tat et
p1 = 0.00016577 pour le bon tat, p0 et p1 tant les paramtres des lois gomtriques des temps
de sjour dans ltat0 et dans ltat1 respectivement.
On prsente dans le paragraphe suivant, les rsultats de simulation obtenus pour les
protocoles UDP et RAP sur un canal modlis de Gilbert-Elliot avec les diffrents paramtres
calculs dans ce paragraphe.
3.7.3 Simulation sur un modle de canal de Gilbert-Elliot
3.7.3.1 Description de la simulation
Pour simuler les deux protocoles RAP et UDP et comparer leur fonctionnement dans le
paragraphe 3.7.1, un canal rel a t considr. Pour un canal simul, on considre le modle
simplifi de Gilbert-Elliot (cf. paragraphe 3.3) et les paramtres calculs dans le paragraphe

Universit Paris-Est
3.7.2 partir des simulations sur le canal rel. On sintresse dans RAP aux taux de pertes
paquets (PER). Au niveau du rcepteur, le calcul du PER permettra destimer les paramtres du
modle du canal et de dterminer sa nature : bon, moyen ou mauvais. Cette indication pourra
tre exploite par lapplication embarque afin dadapter les messages de linterface homme-
machine en fonction de ce contexte. Cette aptitude devra permettre dindiquer lutilisateur le
niveau de confiance quil peut accorder son dispositif dassistance.
Le modle optimis du canal de Gilbert-Elliot a les caractristiques suivantes:
- Deux tats: tat0 (mauvais) et tat1 (bon) ; la dure de sjour dans chaque tat suit une
loi gomtrique de paramtre ps calcul dans le paragraphe 3.7.2 partir des
histogrammes du canal rel. p0 = 0.00058213 pour ltat0 et p1= 0.00016577 pour ltat1.
- Taille du paquet considr (en nombre de bits) = 1184 bits (cf. paragraphe 3.7.2)
- BERm= 0.05 pour le mauvais tat (tat0) et BERb = 0 pour le bon tat (tat 1).
- Une fois dans ltat 0, on reste dans cet tat pendant X bits (X suit une loi gomtrique de
paramtre p0 dj calcul), puis on passe ltat 1 ayant un BER = 0; on reste dans cet
tat pendant X bits (X suit une loi gomtrique de paramtre p1 dj calcul) puis on
passe ltat 1 ayant un BER = 0.05.
Les rsultats de la simulation sur OMNeT++ de ce canal de Gilbert-Elliot et des

protocoles UDP et RAP sont rcapituls dans le tableau 11 ci-dessous, ils montrent que le
protocole RAP est clairement plus fiable quUDP en termes de taux de paquets perdus.
3.7.3.2 Tableau comparatif (UDP vs. RAP sur un canal de Gilbert-Elliot)
UDP est simul sur le canal modlis de Gilbert-Elliot (n=1, nombre de rptitions du
paquet pour UDP, chaque paquet est envoy en une seule copie). Pour RAP, on fait varier le
nombre n de rptitions des trames: n = 2 puis 3, 4 et 5. Le tableau 11 suivant rcapitule les
rsultats de simulation sur un canal modlis de Gilbert-Elliot (optimis de mauvaise qualit):
Paramtre Taux de perte UDP Taux de perte RAP (2)

n=1 7875/30000
n=2 4036/30000 (15849/60000)
n=3 2023/30000 (23821/90000)
n=4 1085/30000 (31706/120000)
n=5 565/30000 (39781/150000)
Table 11- UDP vs. RAP (canal Gilbert-Elliot optimis et de mauvaise qualit)
Le tableau 12 montre les rsultats obtenus pour le canal de qualit moyenne, BER= 0.001 dans
le mauvais tat (PER= 0.69), et pour le canal de bonne qualit, BER=0.0005 (PER= 0.44);
ces rsultats sont donns pour le protocole UDP et pour le protocole RAP avec n = 3.
2
Nombre de rptitions perdues

Universit Paris-Est
Paramtre Taux de perte Taux de perte Taux de perte avec

(canal de mauvaise qualit) (canal de qualit moyenne) (canal de bonne qualit)
n=1 (UDP) 7875/30000 (7875/30000) 5461/30000 (5461/30000) 3479/30000 (3479/30000)
n=3 2023/30000 (23821/90000) 681/30000 (16432/90000) 174/30000 (10463/90000)
Table 12- Canal de mauvaise, moyenne et bonne qualit
3.7.3.3 Histogrammes du canal de mauvaise qualit de Gilbert-Elliot
On montre dans la figure 31 suivante les histogrammes tras dans le cas du canal de
Gilbert-Elliot de mauvaise qualit (laxe des x dtermine le nombre de paquets conscutifs et
laxe des y le nombre de fois que ce nombre conscutif a t observ) pour les bons et les
mauvais tats (les graphes de gauche concernent les paquets conscutifs dans le bon tat et ceux
de droite les paquets conscutifs errons du mauvais tat), et ce pour les deux cas dUDP et RAP
(avec un nombre n de rptitions gal 3):
700 2000
UDP sur un canal de Gilbert-Elliot UDP sur un canal de Gilbert-Elliot
600
-Bon tat- -Mauvais tat-
1500
500
400
1000
300
200
500
100
0 0
0 50 100 150 200 250 300 1 2 3 4 5 6 7 8 9 10
2500 6000
RAP n=3 sur un canal de Gilbert-Elliot RAP n=3 sur un canal de Gilbert-Elliot
-Bon tat- 5000 -Mauvais tat-
2000
4000
1500
3000
1000
2000
500 1000
0 0
0 50 100 150 200 250 300 1 2 3 4 5 6 7 8 9 10
un canal de Gilbert-Elliot

Universit Paris-Est
3.7.4 Comparaison UDP - RAP

On rcapitule dans le tableau 13 suivant les rsultats de simulation des deux protocoles
UDP et RAP sur un canal rel puis sur un canal de Gilbert-Elliot de qualit moyenne.
Protocole UDP RAP (n=3)

Canal Canal Canal Canal
Rsultats Simul Rel Simul
Rel
Longueur 148 148 148 148
du paquet
(octets)
Paquets 30000 30000 30000 30000
gnrs
Rptitions 30000 30000 90000 90000
gnres
Paquets 6642 5461 680 681
perdus
Rptitions 6642 5461 19415 16432
perdues
PER 6642/30000=0.2214 5461/30000=0.182 680/30000=0.0226 681/30000=0.0227
Table 13- RAP vs. UDP (canal rel et canal simul)
3.7.5 Analyse
Daprs les simulations faites sur le canal rel et sur le canal simul de Gilbert-Elliot, le
protocole RAP propos semble tre bien adapt au genre de trafic quon rencontre dans
RAMPE/INFOMOVILLE prcisment pour la transmission en mode broadcast des messages
urgents envoys depuis la borne vers les PDAs travers une liaison radio WiFi. Le mcanisme
de redondance des paquets quil propose, rend la communication plus fiable, en permettant un
taux derreur paquets infrieur celui que subit le protocole UDP. Ce taux de perte paquets
(PER) qui pourra tre calcul par le serveur recevant les trames rptes et numrotes, lui
permettra didentifier le type de canal, et pourra servir laborer un indicateur de la qualit du
lien WiFi qui sera exploit au niveau de lapplication embarque du PDA, lui permettant de
fournir lutilisateur un degr de confiance en son dispositif dassistance.
Le PER calcul pourra tre de mme communiqu au client, par des trames statistiques envoyes
depuis le serveur; en fonction de la valeur de ce PER, le client peut augmenter ou diminuer le
nombre de rptitions (c..d la valeur du paramtre n du protocole RAP dsignant le nombre de
fois de rptition dun paquet), vitant un grand nombre de rptitions quand le canal est dune
bonne qualit et vice versa.

Universit Paris-Est
Chapitre 4- Positionnement et Guidage dans RAMPE/INFOMOVILLE
Chapitre 4
Positionnement et guidage dans RAMPE/INFOMOVILLE
4.1 Introduction
Le dplacement dans lenvironnement des systmes de transports publics ainsi que le
cheminement pitonnier pour y accder reprsentent, pour les personnes dficience visuelle,
des tches complexes pratiquer. La mise en place dun systme daide disposant dun module
de positionnement et de guidage devrait permettre de faciliter certaines de ces tches.
Dans la version actuelle de RAMPE/INFOMOVILLE, lutilisateur de lapplication peut

faire sonner la borne installe dans une station de bus afin de reprer auditivement sa position et
sorienter vers cette station. Toutefois, la PAM peut tre loin de la station et ne pas arriver
entendre la sonnerie surtout lorsquil est dans un milieu bruit (aux alentours de 80dBa mesur
en moyenne durant les exprimentations effectues Lyon). Dautre part, plusieurs trajets
peuvent exister pour aboutir la station dsire, des obstacles peuvent tre prsents et empcher
un trajet en ligne droite. Il semble donc utile dintgrer dans le systme
RAMPE/INFOMOVILLE un service de localisation et dorientation pour accompagner et
assister les PAM. Ce systme doit tre fiable de faon assister efficacement lutilisateur sans
lui faire prendre de risque. Il doit aider la personne sorienter vers sa destination en vitant
autant que possible les trajets difficiles encombrs tout en fournissant les informations de
localisation et de guidage au bon moment et dune faon comprhensible.
Plusieurs travaux ont port sur la localisation pour laide et lassistance au dplacement
des personnes malvoyantes. Les systmes proposs se basent pour la plupart sur la technique de
positionnement GPS et se limitent donc la localisation en outdoor. Certains systmes
exprimentaux utilisent les ondes radio ou infra-rouge comme support la localisation en milieu
indoor. Le systme Strider [49] dvelopp en Californie utilise le GPS et des cartes de
plusieurs villes des Etats-Unis afin de localiser la PAM et lui donner des informations sur son
environnement; MoBic (Mobility of Blind and Elderly People Interacting with Computers),
projet dvelopp luniversit Magdeburg en Allemagne [121] a propos dutiliser le GPS
diffrentiel (DGPS) et un module de dtermination de lorientation. Un autre systme bas sur le
GPS a t dvelopp au Japon par lquipe de Makino [122] luniversit de Niigata. Il utilise le
tlphone mobile comme interface entre lutilisateur et le serveur de localisation et de guidage
contenant les informations gographiques; le Personal Guidance System propos par Loomis
en 1998, utilise le DGPS [49]; en 2008, la compagnie HumanWare, base au Canada et
spcialise dans les dispositifs dassistance aux personnes aveugles propose un GPS parlant
appel Trekker Breeze [50]. Il a t conu pour tre utilis dune seule main. Parmi les
informations vocales fournies par le systme, on peut citer les noms des rues, des points
dintrt, lannonce du prochain arrt dans le bus.
Pour le service de localisation et de guidage intgr dans RAMPE/INFOMOVILLE on a

choisi dutiliser la technologie WiFi pour les raisons dj exprimes prcdemment ; savoir
utiliser la mme technologie que pour la communication de faon rutiliser les mmes
infrastructures, utiliser des technologies gnriques disponibles sur les PDA ou smartphones
(aujourdhui on dispose de GPS, WiFi, Bluetooth), pouvoir effectuer une localisation en indoor

Universit Paris-Est
et en outdoor, permettre une prcision suffisante, avoir une couverture suffisante en extrieur
avec un nombre limit dquipements dinfratructure. Lutilisation de WiFi nest pas exclusive.
Elle pouurait tre associe au GPS en outdoor. Le GPS seul nest cependant pas suffisant en
indoor. La technologie Bluetooth pourrait tre employe mais elle ncessiterait linstallation
dune infrastructure supplmentaire et sa couverture est plus faible. Nous navons pas retenu la
technologie Zigbee car il ny a gnralement pas de carte zigbee dans un PDA ou un
smartphone. Nous navons pas retenu la localisation par systme de communication cellulaire
cause de son manque de prcision.
4.2 Principes dun systme de localisation radio et

infrastructure ncessaire
Comme indiqu dans le chapitre 2, il existe plusieurs mthodes de localisation utilisant
WiFi. Cependant peu de mthodes permettent dapporter une prcision suffisante pour une
application comme RAMPE/INFOMOVILLE.
Les systmes comme AirLocation [76] et AeroScout [77] utilisent la technique TDoA
avec WiFi mais ncessitent du hardware supplmentaire (des points daccs ou des rcepteurs
spcifiques) pour mesurer cette diffrence de temps. Dautre part ces mthodes, bien quelles
aient montr une bonne performance dans les zones outdoor, ne sont pas assez performantes en
indoor cause des interfrences multi-trajets [52].
La mthode statistique base sur les mesures de la puissance des signaux reus (RSS) et
sur la technique dempreinte radio en WiFi offre les caractristiques recherches en termes de
prcision et ne ncessite pas dinfrastructure spcifique supplmentaire lexception du serveur
de localisation. Aussi avons-nous retenu cette technique. Nous en avons dcrit le principe dans
le chapitre 2. Cette mthode a t propose en 2000 par Bahl and Padmanabhan dans un premier
systme appel RADAR [29, 38] utilisant les ondes radiofrquences mises par des interfaces
rseaux. Elle consiste en deux phases: la premire phase appele Calibrage ou
Apprentissage , consiste prendre des mesures de RSSI et sauvegarder ces mesures dans
une base de donnes, et la deuxime phase appele Localisation consiste calculer la
position des terminaux mobiles partir des mesures sauvegardes dans la base de donnes. On
parle dans la littrature de machine learning qui consiste en un apprentissage automatique
partir dexemples [155].
Nous dtaillons dans les sections suivantes les aspects pratiques des deux phases de la mthode
dempreinte digitale en prcisant les lments ncessaires de chacune.
4.2.1 Calibrage
Les lments ncessaires de cette phase sont :
- Un plan du site (diffrents formats sont possibles : JPG, Autocad, GIF, BMP, selon le
logiciel utilis)
- Des points daccs rpartis sur le site
- Un ordinateur quip dune carte WiFi avec le logiciel de calibrage install et
communiquant avec une base de donnes (carte dempreinte radio)
- Un serveur de base de donnes (le logiciel de calibrage et la base de donnes peuvent
tre prsents sur le mme serveur).

Universit Paris-Est
La phase de calibrage consiste se dplacer sur lensemble du site avec lordinateur quip de
linterface WiFi. Au cours du dplacement des mesures sont effectues rgulirement.
Lordinateur se trouvant chaque fois dans la zone de couverture dun ou de plusieurs points
daccs (APs) (sans tre ncessairement associ un AP sauf sil doit communiquer avec la base
de donnes connecte au rseau si cette base de donnes nest pas installe sur le mme
ordinateur), le logiciel de calibrage mesure les puissances des diffrents signaux reus des APs
(RSSs) et les sauvegarde dans la base de donnes. On appelle chantillon lensemble form des
adresses MAC des APs et des puissances des signaux reus de ces APs, ainsi que les
coordonnes cartsiennes du point du site o la mesure a t effectue. Les mmes tapes sont
rptes pour plusieurs points du site.
Figure 32- Phase de calibrage de la mthode d'empreinte digitale
4.2.2 Positionnement
Pour cette phase, les lments suivants doivent tre prsents :
- Un plan du site dj calibr durant la premire phase (la carte dempreinte radio du site)
- Un ordinateur sur lequel est install le logiciel de positionnement. Cet ordinateur doit
tre connect au rseau (connexion filaire ou connexion sans fil et dans ce dernier cas il
est associ un AP) afin de pouvoir communiquer avec le terminal mobile localiser.
Toutefois, le logiciel de calibrage, le logiciel de positionnement et la base de donnes
peuvent tre installs sur le mme serveur.
- Un/des terminaux mobiles localiser ayant une carte WiFi.
Le terminal mobile, dont on cherche la position, mesure les RSSI des APs dans la zone de
couverture desquels il se situe. Il envoie ces mesures au logiciel de positionnement. Ce terminal
mobile doit alors sassocier un AP prsent sur le site (c..d se connecter au rseau) afin de
pouvoir communiquer avec le logiciel de positionnement install sur un serveur lui aussi
connect au rseau.

Universit Paris-Est
Figure 33- Phase de localisation de la mthode d'empreinte radio
Quand le logiciel de positionnement reoit les mesures (adresses MAC APs- RSSI) de la part
des clients mobiles, il compare ces mesures aux mesures rfrences (points chantillons) dj
apprises durant la phase de calibrage, afin den estimer la position de lobjet.
4.2.2.1 Algorithmes de positionnement
Cependant, et vu les variations non-linaires des RSSI et la susceptibilit des ondes radio
aux erreurs et diffrents facteurs qui peuvent affecter leur qualit, la simple comparaison des
mesures reues du client mobile avec les mesures prises dans un temps prcdent et qui sont
sauvegardes dans la base donnes ne sera pas prcise. Il est donc ncessaire dutiliser certains
algorithmes ou mthodes pour lestimation de la position afin de bien exploiter les mesures
releves durant la phase de calibrage [63]. En effet, ces mesures nont t effectues quen
certains points et il faut interpoler au mieux en tous les points de la zone de localisation.
Plusieurs algorithmes sont utiliss ce propos : des algorithmes simples comme celui des
k plus proches voisins (en anglais k-Nearest Neighbor ou k-NN) (appel par Roos, Misikangas et
Sievnen [155] les mthodes case-based), aux mthodes statistiques plus complexes comme
les modles de Markov cachs (Hidden Markov model ou HMM) et les approches baysiennes.
Lalgorithme k-NN calcule la distance euclidienne [150] entre les puissances des signaux
mesures et celles sauvegardes dans la base de donnes. Supposons que les puissances
transmises par lobjet mobile soient notes SSi (puissance du signal reu de lAPi). Lagorithme
cherchera dans la base de donnes, les chantillons de la mme srie dAPs (soit AP1, AP2, AP3
APn), et calculera, pour chaque chantillon trouv, la distance euclidienne entre les
puissances transmises par lobjet mobile et les puissances sauvegardes dans la base de donnes
ssi, distance qui est de la forme:

Universit Paris-Est
Pour dterminer la position de lobjet, les k chantillons ayant la plus petite distance aux
mesures transmises par lobjet mobile sont retenus, la moyenne des coordonnes cartsiennes
associes ces k chantillons est calcule, et la position estime. Des tudes ont montr quune
bonne prcision de localisation est obtenue avec une valeur de k gale 4 [29]. Le systme
RADAR [38] utilise cet algorithme de Nearest Neighbor.
Le systme Ekahau qui sera utilis dans lexprimentation du pragraphe 4.5 utilise, en plus de
lalgorithme k-NN, une approche baysienne (Maximum A Posteriori ou MAP distribution) et
les modles de Markov cachs avec lalgorithme de Viterbi pour lestimation de position durant
le mouvement. Le positionnement est alors bas sur lhistorique des RSSI enregistrs durant la
phase de calibrage ce qui augmentera la prcision de localisation.
On explique lapproche baysienne en donnant certaines notations, variables et quations:
On note par l la variable indiquant la position de lobjet et par o la variable dobservation (ou
vecteur correspondant aux RSSI relevs durant la phase de calibrage). Les n chantillons de la
base de donnes sont nots par li oi tel que i {1, , n}.
Le modle estime la probabilit de distribution de la variable o tant donn la valeur de la

variable l; on parle de la probabilit conditionnelle note p(o|l).
On applique la rgle de Bayes pour obtenir la distribution posteriori p(l|o) [64, 65, 151, 152,
155] :
p(l) tant la probabilit priori que lobjet soit lendroit l, avant de connatre la valeur de la
variable dobservation o.
p(o) ne dpend pas de la variable dendroit l et pourra tre remplace par une constante
normalise, dans les cas o seulement les probabilits relatives ou les rapports de probabilit
sont requis.
La position correspondant la probabilit maximale obtenue sera retenue pour lestimation de

position du client mobile par le serveur de positionnement.
En considrant des p(l) uniformes, p(o|l) peut dterminer la probabilit posteriori p(l|o)
dune certaine position de lobjet et donc il est important que le calcul de cette probabilit
conditionnelle p(o|l) (nomme fonction de vraisemblance ou likelihood function) soit le plus

Universit Paris-Est
prcis possible. Deux mthodes possibles destimation de cette distribution statistique partir
dobservations sont la mthode des histogrammes et la mthode des noyaux (Kernel method).
La mthode des noyaux est une mthode dajustement de distribution statistique non
paramtrique des observations, quivalente une mthode dhistogramme liss. Elle consiste
attribuer une fonction noyau (masse de probablit) chacun des vecteurs dobservations relevs
pendant le calibrage pour une position donne de lobjet. Dans ce cas, p(o|l) sera gale :
Tel que nl dsigne le nombre de vecteurs chantillons relevs pour la position l et K est la
fonction noyau ; une fonction noyau trs utilise est la fonction Gaussienne qui est de la forme:
tant un paramtre ajustable qui spcifie la largeur du noyeau autour de chaque chantillon de
mesure.
Dans la mthode des histogrammes, on considre la variable dobservation o comme

ayant un minimum min et un maximum max ; lintervalle (min max) est divis en k
intervalles spars (appels bins en anglais). Pour simplifier les calculs, les intervalles peuvent
tre de mme largeur w et disposs comme suit :
[min + i w, min + (i + 1) w] tel que 0 i <k et
On calcule la proportion dobservations comprises dans chaque intervalle. La probabilit des

intervalle dtermine la fonction p(o|l). Cette probabilit correspond aux frquences relatives des
intervalles de lhistogramme.
Dautre part Ekahau se base sur les modles de Markov cachs [71] pour estimer la
position dun client mobile quand il est en mouvement. Ce modle permet de repsenter un
processus de Markov pour lequel certains tats sont non observables ; des informations sur ces
tats peuvent tre dduites de donnes observes.
Supposons que les diffrentes positions possibles dun client mobile soient {l0, , ln} et que st
dsigne ltat (la position) du client mobile linstant t.
La probabilit de transition dun tat i un tat j est donne par a(i,j) = p(st+1=lj | st=li).
d(m) = p(s0=m) est la probabilit dtre l'tat m l'instant initial.
{o1, ..., oj} reprsentent les diffrentes observations releves et b(m, k) = p(ot=k | st=m)
dsigne la probabilit que le client mette un signal o = k lorsquil est dans ltat m linstant
t.

Universit Paris-Est
Ainsi, les tats st, les oj ainsi que les probabilits a(i,j), b (m,k) et d(m) caractrisent le
modle de Markov cach.
Lalgorithme de Viterbi [174] permet destimer la squence d'tats {l1,..., ln} la plus probable
qui a engendr les observations obtenues, appele chemin de Viterbi.
La probabilit du chemin le plus probable atteignant ltat si linstant i est compose du
chemin le plus probable atteignant sm ltape i-1 et de la transition entre les deux tats sm et si
et peut tre calcule rcursivement selon la formule :
Ainsi chaque tat a un prdcesseur, ce qui servira retrouver la squence dtats ayant
engendr les observations obtenues.
Le banc de test de lexprimentation ralis par Roos, Misikangas et Sievnen [155, 172]
tait le suivant : un tage de surface 40m16 m avec dix APs utiliss. Des cchantillons ont t
enregistrs dans 155 endroits du site disposs sous forme de grille et espacs de 2m lun de
lautre; de plus des chantillons ont t enregistrs dans 120 endroits situs au milieu des
cellules de la grille. Ces exprimentations ont montr des erreurs destimation de position faibles
en adoptant les techniques statistiques par rapport lalgorithme k-NN ; dautre part, la mthode
des noyeaux a montr des erreurs faibles par rapport la mthode des histogrammes quand les
observations dun seul chantillon sont considres, tandis que la mthode des histogrammes a
donn de meilleurs rsultats quand plusieurs chantillons sont utiliss (pour la mthode des
histogrammes 5.4 m derreur avec un seul chantillon et 2.8 m avec 20 chantillons utiliss ;
dans la mthode des noyaux, lerreur est de 4.6 m et 3.1 m pour un chantillon et pour 20
chantillons utiliss respectivement).
Le systme de localisation par WiFi Horus [34] utilise aussi les mthodes
probabilistiques; de mme que le systme Nibble [65] mais ce dernier se base sur les rapports
signal sur buit (SNR pour Signal to Noise Ratio) pour faire le calibrage plutt que sur les RSSI.
Une fois la position de lobjet mobile estime par le serveur de positionnement, elle
pourra tre transmise sur demande une troisime entit. Ceci peut tre intressant pour le cas
de RAMPE/INFOMOVILLE : le logiciel de positionnement peut tre install sur le serveur de la
station de bus et aprs le calcul de la position du PDA (ou smartphone) port par la PAM, il peut
transmettre cette position au PDA qui cherche se localiser, ou bien encore, il peut
communiquer la position du PDA port par la PAM un autre PDA port par une personne qui
cherche localiser la PAM afin daller sa rencontre pour laider.
Plusieurs facteurs peuvent influencer la prcision de localisation (la diffrence entre la

position relle de lobjet et la position calcule par le systme) obtenue avec un tel systme: le
nombre de points daccs prsents sur le site (la localisation base sur WiFi ne fournit pas
toujours une bonne prcision dans les milieux extrieurs cause du fait que la densit des points
daccs installs en outdoor est plus petite que leur densit en indoor [51], la disposition de ces
points daccs, la mthodologie de calibrage utilise (des tudes ont montr que la prcision de
la localisation en WiFi peut tre amliore par calibrage [51]), les caractristiques
environnementales du milieu (obstacles, perturbations, interfrences, etc), la mobilit des
dispositifs (des observations ont montr que pour les rcepteurs WiFi en mouvement, les
puissances des signaux reus prsentent une plus grande dispersion que pour les terminaux fixes
[53], leurs cartes WiFi, etc.

Universit Paris-Est
4.2.3 Systme Ekahau

Dans lexprimentation dcrite au paragraphe 4.5 de ce chapitre, dont lobjectif est de
proposer un systme de localisation et de guidage pouvant tre intgr dans
RAMPE/INFOMOVILLE, on utilise le systme Ekahau de localisation en temps rel par ondes
WiFi adoptant la technique dempreinte radio [43]. Ce systme consiste en:
- des Clients Agents

- des Etiquettes Ekahau portes par les dispositifs localiser (optionnelles)
- logiciel de calibrage (nomm Ekahau Manager)
- logiciel de positionnement (nomm Ekahau Positioning Engine (EPE))
- le logiciel facultatif dapplications Ekahau pour les utilisateurs accdant l'information
de localisation
Le tableau 14 dcrit les fonctionnalits des diffrents lments du systme Ekahau et les
plateformes adquates pour chacun:
Composant Fonctionnalits Plateformes

supportes
Client Logiciel install sur le dispositif localiser (qui peut tre un Windows Vista,
Agent ordinateur portable, un ordinateur de poche de type PDA, etc). XP, 2000, Pocket
PC 2002 et 2003,
windows mobile
Etiquette Petite tiquette radio qui peut tre attache n'importe quel objet
WiFi mobile quon cherche localiser ou aussi porte par des personnes
(qui ne possdent pas un dispositif avec carte WiFi). Cette tiquette
comprend un metteur WiFi.
Ekahau Application permettant de crer des modles de positionnement et les Windows 2000,
Manager sauvegarder dans la base de donnes de l'Ekahau Positioning Engine XP Professional et
ou Ekahau 2003 Server
site survey
(ESS)
Ekahau Bas sur Java, ce serveur calcule la position des quipements WiFi. Il Windows 2000,
Positioning fournit l'information de position de lagent en coordonnes XP Professional et
Engine cartsiennes avec une indication de la qualit de lestimation. Il est 2003 Server, linux
(EPE) compatible avec tous les points d'accs WiFi 802.11a/b/g
Table 14- Composants du systme Ekahau
Pour l'implmentation du systme Ekahau, les lments suivants doivent tre prsents:
Le serveur de localisation qui est un PC avec le logiciel EPE : au minimum un

processeur de 1 GHz x86, 256 MB de RAM, 200 MB de disque dur, avec Windows XP,
2000, 2003 Server ou Linux
Un PC portable avec le logiciel ESS servant faire le calibrage (site survey) : le portable
doit comporter au minimum un processeur Pentium III, 512 MB RAM, 200 MB HD et
Windows XP Professional, Windows 2000 ou Windows 2003 Server. Ce portable doit
aussi tre quip du logiciel client de localisation (on lappelle par la suite client agent ou
client ou client mobile).

Universit Paris-Est
Rseau sans fil : points daccs de la norme 802.11 a/b/g

Le logicile Client Agent Ekahau install sur les PCs ou PDA localiser. Ces objets (PC
ou PDA) localiser doivent utiliser un systme dexploitation de type Windows Pocket
PC 2002 ou 2003, windows mobile 5 ou 6, WinCE 3.0, Windows XP et Windows 2000.
Ces clients Agents supportent des interfaces WiFi spcifiques (bases sur Agere,
Atheros, Broadcom, Texas Instruments ou chip sets Conexant, ).
Ekahau propose quelques indications pour de bons rsultats [43] :
- Avant de commencer le calibrage, ESS permet de choisir les points d'accs qui entreront
dans la construction du modle radio. En effet, les points d'accs dtects n'appartiennent
pas ncessairement au rseau propre la localisation ; ils peuvent appartenir une
entreprise voisine ou simplement tre prsents dans lenvironnement. Ceci peut poser des
problmes et peut fausser les rsultats si ces APs changent de position ou sils tombent
en panne. Pour cela il peut tre est prfrable dviter dutiliser les points d'accs non
dsirs ou incertains dans la localisation.
- L'accroissement du nombre dAPs augmente la prcision de localisation ; pour cela on

peut installer des points d'accs additionnels sans les connecter au rseau. On appellera
ces APs dummy . La configuration des canaux nest pas trs importante car ces APs
n'envoient pas de donnes et ninterfrent pas avec des rseaux informatiques existants.
- L'chelle exacte du site concern doit tre spcifie. On peut faire correspondre un
certain nombre de pixels sur la carte du site avec la distance exacte exprime en mtres
ou en centimtres et mesure rellement sur le site calibrer.
- Des rails de cheminement peuvent tre prciss sur le site calibrer afin de savoir les
chemins possibles sur lesquels le client agent peut se dplacer et avoir alors une
meilleure prcision.
Ekahau utilise une mthode de calcul statistique pour lestimation de la position dun client
agent. Cette mthode a t explique dans le paragraphe 4.2.2.
4.3 Besoins utilisateurs et contraintes dexploitation

Un systme dassistance aux personnes voyageurs aveugles comme
RAMPE/INFOMOVILLE, doit satisfaire aux besoins des utilisateurs du systme et prendre en
compte les contraintes des exploitants.
4.3.1 Besoins utilisateurs

Plusieurs tudes [116, 118, 123] et exprimentations [8, 62] ont t prsentes dans la
littrature sur les besoins des PAM au cours de leurs dplacements. Au cours du projet
INFOMOVILLE, une analyse relle in-situ des dplacements naturels des personnes dans les
transports publics a t ralise [117, 124].
Cette tude et lanalyse de la littrature ainsi que lexprience acquise prcdemment par les
ergonomes du projet (Grard Uzan et Marie-France Dessaigne) ont permis de faire merger les

Universit Paris-Est
stratgies de dplacement des PAM et de mettre en vidence leurs besoins. Ces besoins peuvent
tre diviss en quatre catgories prioritaires [8, 61, 93, 96, 117, 119] :
Besoins en scurit
viter les chutes, les chocs, les risques de collision. viter les risques lis aux situations
dgrades, et la sret.
Plusieurs systmes ont t dvelopps pour aider les PAM dtecter la prsence dobstacles :
canne blanche, mowat sensors, (cf. chapitre 1). Les PAM durant leurs dplacements
cherchent emprunter des chemins faciles prsentant peu dobstacles et de risques chutes ou
encore des chemins familiers.
Besoins en localisation
On peut distinguer deux types de localisation [93, 116]:
- l'auto-localisation qui permet de se localiser dans l'espace immdiat (hall, couloir,

escalier), un peu plus distant (station gare ou quartier) ou plus global (rseau, ville). Lauto-
localisation correspond la question O suis-je?
- lallo-localisation : localisation d'lments de l'environnement immdiat ou un peu plus

distant (escalier, couloirs, guichet, ligne de contrle, quai, sige, services, commerces, entre
et sortie des quais) et trs distant (autre point de transport, rues, ...). Lallo-localisation
correspond la question Quy a-t-il autour de moi ?
Dune faon gnrale, la PAM essaye de dcouvrir le site et lenvironnement o il se

trouve (topographie et topologie, distribution fonctionnelle) ; il cherche vrifier lexistence des
stations de transport sa proximit.
Besoins en orientation
Il sagit de pouvoir maintenir une trajectoire la fois lors du dplacement et dans sa

reprsentation mentale, respecter un itinraire, accder une destination intermdiaire ou finale
du dplacement.
Besoins en informations
Les besoins en informations concernent toutes les activits du lieu, qu'elles soient ou non
ddies au(x) transport(s).
Pour les informations non lies au transport, on peut citer les informations de scurit (prsence
dobstacles, descaliers,), les informations de localisation et dorientation (dtailles dans le
paragraphe suivant).
Grard Uzan [96, 119, 131] distingue pour l'interface, les tches descriptives destines la
connaissance des sites (topographie et topologie, distribution fonctionnelle) et les tches
d'orientation destines au guidage ou sa correction.
Quant aux informations lies au transport, on peut les sparer en trois catgories :

Universit Paris-Est
- Les informations dexistence, didentification et de localisation des arrts : inventaire des

stations proximit du voyageur, noms des stations, reprage de la position des stations.
- Les informations de parcours (lignes, directions, stations desservis, horaires ).
- Les informations vnementielles (bus l'approche, panne, changement dhoraire,

accident sur une ligne ...).
Dans RAMPE/INFOMOVILLE, lobjectif est de pouvoir fournir lutilisateur la bonne

information au bon moment et au bon endroit. Pour cela, ces informations lies au transport ont
t actualises selon trois niveaux temporels [8] :
Informations structurelles : ce sont les informations prdfinies et stables ; localisation et

identification des arrts, lignes desservies, parcours, horaires, etc. Ces informations
permettent au PAM de dcouvrir son environnement en terme de transport et de planifier
son dplacement.
Informations temporaires : ce sont les informations structurelles mais exceptionnellement

modifies pour une dure limite (changement de place d'un arrt, dtournement
provisoire d'une ligne,). En labsence dinformation sur ces perturbations ou situations
inhabituelles, la PAM pourra par exemple attendre un bus un arrt alors que pour des
raisons exceptionnelles la ligne de bus est dtourne et larrt nest pas desservi.
Les informations immdiates d'urgence : ce sont les informations "temps rel" (bus
l'approche, changement de parcours, terminus, retard, accident ).
Une analyse thorique effectue lors du projet RAMPE a permis de modliser le dplacement en
quatre zones spatiales qui permettent de comprendre en quoi un mode de transport est plus
"accessible" qu'un autre et quelles sont les spcifications pertinentes d'un systme d'information
[8]. On distingue :
La zone ouverte de la voirie et du bti. Cette zone se caractrise par la diversit et la

mixit des activits (dplacements, habitations, commerces, culture,...) et par la diversit
des moyens de dplacement utiliss (vhicules privs ou de transport en commun,
pitons - deux roues automobiles bus - tramways...) ; les espaces n'y sont pas
ncessairement ddis, et quand ils le sont, ils peuvent ne pas l'tre strictement, soit
formellement soit travers les usages ; c'est une zone qui peut tre soumise des
niveaux de bruit levs (souvent plus de 75 dBa) en permanence. Les informations utiles
sont des informations d'existence et de localisation des arrts
.
Zone daccs : zone ddie un systme de transport (hall de gare, couloir de mtro, file
d'attente de taxis ...). Elle se caractrise par l'unicit fonctionnelle: la plupart des
individus qui s'y trouvent ont pour but de prendre ou quitter un vhicule de transport
public. Espace dlimit o ne circule que des pitons, cette zone est un espace stable qui
peut donc tre facilement mmoris. Dans ces zones, les PAM bnficient de la
"communaut de but" induite par la zone. Ils peuvent ainsi utiliser l'assistance humaine
de guidage et d'information "par les autres voyageurs". Cette assistance trouve ces
limites dans les erreurs (rats de parcours et lapsus de localisation ou de destination) et

Universit Paris-Est
dans les situations de lieux et horaires peu frquents. Les informations utiles sont des
informations de guidage vers une zone de transfert.
Zone de transfert, appele aussi zone d'accostage. Il sagit du lieu dentre ou de sortie
du vhicule (extrieur de vhicule, portes et zone de seuil, lacune, quai, trottoir et plus
largement zone d'accueil). Cest une zone de risque pour les PAM (collision, chutes,
accidents) et une zone dincertitude et de charge mentale. Cette zone entrane des
stratgies exploratoires par ttonnements ncessitant du guidage. Les informations utiles
sont des informations vnementielles et des informations de guidage (position de la
porte), ainsi que des informations lies des proccupations de scurit
Zone intrieure au vhicule : zone dans laquelle le voyageur devient statique. Sa charge
mentale peut ventuellement diminuer. Les informations utiles concernent la progression
du dplacement, le prochain arrt, les correspondances.
De faon gnrale, on peut distinguer pour l'interface, les tches descriptives destines la
connaissance des sites (topographie et topologie, distribution fonctionnelle) et les tches
d'orientation destines au guidage ou sa correction.
Dans le cadre des projets RAMPE/INFOMOVILLE, la spcification des systmes a t

effectue en considrant le dplacement de bout en bout avec une utilisation des transports
publics (bus, tramway, metro, train), en prenant en compte certaines proprits importantes
(familiarit avec le trajet ou le mode de transport utilis) et en cherchant aider lutilisateur
avoir une bonne reprsentation mentale de sa situation relle durant le parcours. Lensemble des
dplacements possibles a t formaliss travers trois types de scnarios lmentaires :
Scnario simple: la PAM part dun lieu (la maison par exemple), va pied au point
darrt de dpart A, prend le transport, descend au point darrive B, et termine le
dplacement pied jusqu sa destination.
Scnario 2: la PAM part dun lieu (la maison par exemple), va pied au point darrt de
dpart A, prend le transport, descend au point darrt B pour un changement de ligne,
attend au mme point darrt qui devient un point de dpart, reprend le transport et
descend au point darrive C, puis va sa destination pied.
Scnario 3 : la PAM part dun lieu (la maison par exemple), va pied au point darrt de
dpart A, prend le transport, descend au point darrive B, puis fait un changement : il
marche jusqu un nouveau point darrt de dpart C, prend le transport (ce nest pas
forcment le mme mode de transport), descend au point darrt darrive D et va sa
destination pied.
Dans ce contexte, les applications possibles de la localisation et ventuellement du

guidage pour un piton PAM sont nombreuses. Par exemple :
- La PAM veut localiser une borne ;
- Lapplication sur PDA veut savoir o est la PAM pour lui dlivrer les messages
dinformation utiles dans la zone o il se situe ;
- Lapplication sur PDA guide la PAM en vitant les chemins difficiles et encombrs ;
- Une personne veut localiser une autre personne. Par exemple on peut imaginer que des
agents dans une gare ou un ple dchanges compliqu soient charges daller aider

Universit Paris-Est
les PAM. Ces agents pourraient disposer de PDA (ou smartphones) sur lesquels
safficherait une carte avec la position de la personne aveugle aller chercher ;
- La borne pourrait vouloir localiser un PAM pour sonner plus ou moins fort selon la
distance de la personne.
Dans la version initiale de RAMPE/INFOMOVILLE, le seul moyen disponible pour se

guider vers une borne tait de la faire sonner. Mais compte tenu du bruit environnant, cette
technique nest efficace qu une courte distance de la borne (typiquement une dizaine de
mtres). Lors de lexprimentation Lyon, les PAM qui ont test le systme ont indiqu quils
aimeraient disposer dune assistance supplmentaire lors de la traverse des grandes places telle
que connatre la distance approximative de larrt recherch ou savoir si on se dirige dans la
bonne direction.
Les applications dun service de localisation et de guidage dans

RAMPE/INFOMOVILLE sont multiples. Cependant, le systme doit en premier lieu permettre
une bonne prcision de localisation tout en fournissant les informations de localisation et de
guidage dune manire comprhensible ;
Par ailleurs, on ne cherchera pas utiliser la localisation partout mais seulement dans les zones
o elle pourrait tre le plus utile : dans les places complexes par exemple ou les ples
dchanges.
4.3.2 Contraintes dexploitation

La conception du systme intgrant un service de localisation doit aussi prendre en
compte les contraintes des oprateurs de transports qui devront installer, exploiter et maintenir le
systme. Ce systme doit satisfaire plusieurs exigences et contraintes.
Les exploitants dun systme dassistance aux PAM utilisant des technologies de
communication et de localisation devront fournir un systme possdant une qualit de service
suffisante. Dun point de vue technique, tous les lments du systme ont un impact sur la
qualit de service (QoS). La technologie WiFi est llment le plus critique pour les
performances de lapplication en termes de communication et de localisation. La QoS dpend en
particulier de la disponibilit (possibilit de se connecter) et de la fiabilit (possibilit de
recevoir les informations qui ont t transmises) du rseau WiFi en environnement urbain. Ces
deux caractristiques sont relies tant donn que le manque de ressources (affectant la
disponibilit) ou laugmentation du taux dutilisation introduira des collisions et des
congestions, ce qui peut aboutir une perte de donnes et donc un manque de fiabilit. La
bande ISM de 2.45GHz utilise par WiFi est aussi employe pour dautres applications sans fil
comme Bluetooth.
Des mesures radio ont t effectues lors de lexprimentation de RAMPE sur site Lyon [62].
Elles ont t ralises laide dun analyseur de spectre permettant de raliser des mesures
ddies la bande ISM de 100MHz autour de 2.45GHz. Les donnes recuillies sont de deux
types : une cartographie de la puissance dmission du point daccs situ dans le poteau darrt
et un relev de lvolution du spectre radio tout au long de chaque parcours du scnario
dexprimentation.

Universit Paris-Est
Lors de cette exprimentation, le rseau WiFi nest jamais apparu comme un chanon vulnrable
du systme dassistance RAMPE et cela a t confirm par le dpouillement des mesures radio
effectues. Les donnes collectes ont montr un trs fort dploiement de points daccs WiFi en
environnement urbain, puisque sur les sites nous constations couramment une trentaine de points
daccs actifs. Cependant cette prsence de nombreux points daccs ne se traduit pas
aujourdhui par un trafic effectif important qui pourrait poser de problmes dinterfrence et de
disponibilit.
Le profil dutilisation de WiFi en environnement urbain est aujourdhui compatible avec son
utilisation pour un service comme RAMPE. Cependant ce rsultat peut voluer dans les
prochaines annes et loccupation de la bande ISM devrait tre surveille par lexploitant
La simplicit dimplmentation du systme est un autre lment important pour
lexploitant. La technologie 802.11 est de plus en plus rpandue et sa mise en place de plus en
plus simple. Presque tous les terminaux portatifs (PDA, ordinateurs portables) sont quips
dune carte sans fil WiFi. Dautre part, les systmes radio WiFi pouvant oprer dans les milieux
internes et externes rendent possible limplmentation de cette technologie dans toutes les zones
o lapplication dassistance RAMPE/INFOMOVILLE peut tre utile.
La mthode retenue pour la localisation par ondes WiFi est la technique dempreinte digitale qui
est compose de deux phases : calibrage et positionnement. Cette mthode se base sur les
mesures des puissances reues des points daccs qui sont affectes par plusieurs facteurs
comme laffaiblissement sur le parcours, leffet des trajets multiples, . Si les obstacles
stationnaires peuvent tre pris en compte pendant le calibrage, il faudra aussi considrer les
erreurs dues dautres objets et obstacles mobiles se trouvant dans le site.
Le calibrage ncessite un temps important surtout dans les environnements externes de grande
dimensions, tant donn que ce calibrage doit tre fait manuellement [51, 52]; dautre part, ces
environnements demandent des mises jour rgulires puisquils sont susceptibles aux
changements environnementaux. Des tudes ont essay de minimiser ce temps de calibrage ou
de proposer des mthodes de construction de cartes radio sans avoir recours au calibrage. On
peut citer la mthode de sniffers propose par Lus Felipe et Bruno Astuto [52] : elle utilise des
sniffers qui sont des PCs quips dune carte rseau sans fil (WNIC) et dune carte rseau filaire
(NIC) ; un logiciel install sur ces sniffers capture les trames dtectes sur la WNIC et en relve
ladresse MAC dun client mobile ainsi que les RSSI des diffrents AP dans la zone o se trouve
le client.; les sniffers envoient ces valeurs au serveur de localisation connect leur interface
NIC ; ils enregistrent dautre part les RSSI quils reoivent dun ou de plusieurs point daccs
rfrences (APref). Ces deux tches sont excutes simultanment et sans interruption pour
construire le modle de localisation. Les positions des sniffers et celles des APref tant bien
connues, le serveur de localisation pourra en estimer la position de lobjet mobile. Une autre
mthode similaire est propose par Y. Gwon et R. Jain [127] o le serveur de localisation
enregistre simultanment les RSSI transmis par le client mobile (reus des diffrents AP dtects
par ce client) et les RSSI quil reoit des diffrents APs (les positions de ces APs sont bien
connues par le systme) et en construit le modle de positionnement ; en utilisant un algorithme
de triangulation , dinterpolation et dextrapolation, le systme calcule la position du client
mobile ; les rsultats dexprimentation de cette mthode ont montr une prcision de
localisation proche de celle obtenue avec les mthodes de calibration classiques (calibration
manuelle de la mthode dempreinte radio). Un algorithme propos par X. Chai et Q. Yang
[128] essaye de rduire le nombre de points chantillons enregistrs et modlise les traces non
calibrs dun client en mouvement (pour les utiliser durant le positionnement), en utilisant pour
ceci les modles de Markov cachs. F. Gschwandtner et P. Ruppel proposent une mthode de

Universit Paris-Est
calibrage automatique [51] pour les systmes de localisation WiFi utiliss dans les
environnements de grandes dimensions; cette mthode se base sur un deuxime systme de
positionnement (le GPS) qui calcule les coordonnes du terminal mobile WiFi utilis pour la
calibration.
La dure de la phase de calibrage est un lment important pour les exploitants, pour qui le
temps dimplmentation dun systme constitue une contrainte importante.
Une autre proccupation des exploitants est la maintenance et la mise jour du systme. La
principale maintenance va concerner le rseau WiFi. Le service de localisation et de guidage
utilisant les ondes radio WiFi, ncessite la mise en place de points daccs couvrant le site
considr. Comme expliqu au paragraphe 4.2, le nombre de ces APs et leurs emplacements
influent sur la prcision de localisation ; le PDA qui doit reporter les mesures des puissances
reues au serveur de localisation doit pouvoir se connecter au rseau WiFi en tout point de la
zone o est effectue la localisation : tout dplacement dun point daccs peut fausser les
rsultats. Il se peut par exemple que lon fasse des travaux dans un site et que lon dplace des
APs. Lidal dans ce cas, est de refaire le calibrage du site et de mettre jour la base de
donnes ; de mme si certains APs tombent en panne.. Il peut donc tre utile de concevoir un
systme de surveillance automatique de la qualit de la localisation de faon dtecter
automatiquement la ncessit de recalibrer un site (ESIEE Paris travaille actuellement sur ce
sujet). Une autre contrainte est la ncessit dalimenter les APs. On peut les installer dans les
panneaux daffiches lectroniques et partager avec eux une source dalimentation disponible en
ville (clairage public par exemple).
4.4 Proposition dune mthodologie de calibrage avec

chemins privilgis
On propose dans cette thse une mthodologie de calibration qui minimise le temps de
calibrage tout en obtenant une bonne prcision dans la phase de localisation [16] ; on cherche
renforcer cette prcision dans les endroits critiques du site ou plus prcisment dans les zones de
dplacement et sur les chemins que la PAM, dans le cas de RAMPE/INFOMOVILLE, peut
emprunter durant son dplacement dans lenvironnement des transports publics. On parlera de
mthode de chemins Privilgis, quon notera PPs pour Preferred Paths. Le but est dorienter
la PAM vers un de ces chemins pour ensuite le guider tout au long de ce chemin trajets jusqu
la destination.
La mthode consiste faire un double calibrage du site : un calibre uniforme de prcision

moyenne sur tout le site plus un calibrage fin sur les PPs. Le calibrage uniforme consiste
prendre des points chantillons distribus sur le site avec un pas dchantillonnage assez grand,
tandis que ce calibrage devient plus fin sur les PPs (le nombre des chantillons pris sur les PPs
est important) afin davoir une bonne prcision de localisation sur ces PPs. Cela va permettre au
logiciel de positionnement de connatre globalement la position de la PAM ( gauche du PP, sa
droite, etc) afin de le ramener sur lun des PPs et le guider travers ce PP vers la destination ; on
vitera ainsi les trajets difficiles prsentant trop de dtours ou dobstacles. Il sagit ici
dobstacles fixes de positions connues a priori et prsents lors du calibrage.
Les exprimentations de RAMPE Lyon faites sur la place Grange Blanche ont montr
clairement lexistence de chemins privilgis utiliss par les PAM et leurs diffrentes efficacits;

Universit Paris-Est
en particulier, une grande partie des PAM se dplaaient en longeant le bord du trottoir quelles
dtectaient avec leur canne blanche. Cette stratgie sest avre la plus efficace sur cette place de
forme quasi circulaire et de grandes dimensions. Dautres personnes essayaient de traverser la
place en ligne droite mais se heurtaient un ensemble dobstacles tels que des murets ou plots
sur le sol et prouvaient des difficults maintenir une trajectoire rectiligne vers le point de
destination mme en labsence dobstacles (effet dalle).
On value dans les exprimentations dcrites au paragraphe 4.5 lefficacit de cette mthode.
4.5 Exprimentation
Dans ce paragraphe, on value par une exprimentation faite sur le site dun campus
universitaire au nord du Liban, lefficacit de cette approche.
4.5.1 Description du site et de linfrastructure de lexprimentation

Commenons par dcrire le site o la manipulation a eu lieu : il sagit dune zone externe
de forme carre (figures 34 et 35) et dune surface de 50x50m2. Des obstacles sont toutefois
prsents au milieu du site : des arbres, des bacs fleurs, etc. Le site est assez bruyant
(prsence dtudiants, cours deau, voitures se dplaant juste dans une ruelle ct, ...) mais
moins bruyant que les sites urbains des grandes villes. Il est entour de btiments levs prsents
de deux cts du site. Nous y avons install huit APs WiFi pour lexprimentation. Dautres AP
(voisins/interfrents) sont prsents sur le site peuvent tre dtects (7 APs trangers ont t vus).
Tous les APs dtects (installs spcifiquement pour cette exprimentation ou trangers)
peuvent tre utiliss pour le calibrage du site ; cependant, et pour bien contrler les expriences,
on na utilis que les APs spcifiquement installs pour cette exprimentation ; le systme
Ekahau utilis dans lexprimentation donne la possibilit dexclure certains APs
(voisins/interfrents) de la calibration.
Figure 34- Vue Google satellite du site de lexprimentation

Universit Paris-Est
Figure 35- Photos du site d'exprimentation
Dautre part un rseau de communication propre la manipulation a t implment (figure 36).

Il comprend un commutateur (de type Power over Ethernet permettant dalimenter les points
daccs travers le cble utilis pour la connexion au rseau) auquel sont connects 8 points
daccs par une liaison filaire. Chaque AP a une adresse IP fixe. Le logiciel de positionnement
EPE est install sur un ordinateur connect au rseau par une liaison filaire (connect au
commutateur). Une adresse IP fixe lui est attribue. Un serveur DHCP (de type Serveur
Windows 2003) se trouve sur le rseau et permet la distribution automatique des adresses IP aux
clients mobiles (PDAs ou PCs portables). De cette faon, chaque client mobile localiser,
sassocie un certain AP, obtient une adresse IP, ce qui lui permettra, en tout point du site, de se
connecter au rseau et de communiquer avec le logiciel de positionnement pour lui transmettre
les mesures des puissances reues des diffrents APs. Au cours de son dplacement, ce client
mobile peut changer dAPs (roaming) et sassocier un second AP lui assurant un meilleur
rapport signal sur bruit, tout en restant connect au rseau avec la mme adresse IP.

Universit Paris-Est
Figure 36- Infrastructure de la manipulation
4.5.2 Elments de lexprimentation

Le systme Ekahau (une version gratuite) a t utilis dans cette exprimentation. Ce
systme utilise la mthode dempreinte radio avec ses deux phases de Calibrage et de
Positionnement. Les lments suivants sont prsents:
- La carte du site en format JPG (voir cette carte annexe A)

- Huit Points dAccs WiFi Cisco Aironet 1100 Series installs dans le site comme indiqu
dans la figure 37 : avec ces 8 APs on a pu couvrir tout le site i.e on a pu recevoir, en
chaque point, le signal dau moins 3 APs.
- Un portable Windows XP ayant une carte Centrino intgre - Intel Pro/Wireless LAN
2100 3B Mini PCI Adapter. Chipset: Intel 2100, sur lequel tourne Ekahau Manager
(logiciel de calibrage- cf. paragraphe 4.2.3) et Ekahau Engine (faisant les calculs et les
estimations de localisation).
- Des portables et des PDAs localiser avec le client agent install ; Les PDAs utiliss
sont de la marque i-mate. Ce sont des tlphones portables ayant les fonctionnalits dun
ordinateur de poche et fonctionnant avec Windows Mobile comme systme
dexploitation).
Ekahau propose de tracer sur la carte du site (tlcharge dans Ekahau Manager) des rails de
cheminement qui spcifient les chemins possibles o le client localiser peut se trouver et sur
lesquels il peut se dplacer ; ceci fournira au logiciel de positionnement une certaine indication
permettant dobtenir une meilleure prcision. Un rail a par dfaut 7.9 feet (2.4 mtres) de
largeur. Les rails tracs dans notre cas sur la carte du site reprsentent les PPs que laveugle peut
emprunter pour arriver la station. Chaque PP a une largeur de 2.4 mtres (ils sont montrs
hachurs sur la figure 37) (on a aussi trac ces PPs sur le sol du site avec une craie blanche).
Leurs longueurs respectives sont notes dans le tableau 15 suivant :

Universit Paris-Est
Preferred Path Longueur

PP1 42 mtres
PP2 84 mtres
PP3 53 mtres
PP4 44 mtres
Table 15- Longueur des diffrents PPs
10 m
AP2
AP1
PP1
DEST
Preferred Paths AP7

Bac fleurs
AP3
PP2
Bac fleurs
AP8
AP6
AP5
PP4
AP4 PP3
Figure 37- Banc de test de la manipulation de localisation
4.5.3 Scnario de base (scnario 1)- Calibrage uniforme du site
4.5.3.1 Mthodologie de calibration
Dans ce scnario, on utilise les 8 APs pour calibrer tout le site de faon uniforme : en
recueillant un chantillon tous les 4 mtres sur toute la longueur et la largeur du site. Au total,
environ 150 chantillons ont t relevs pour tout le site. Chaque chantillon ncessite
approximativement 6 secondes pour tre enregistr. Cette dure dpend de la carte WiFi utilise
pour le calibrage et de sa vitesse de balayage radio (scan rate), du processeur du serveur de
calibrage et de sa vitesse de connexion la base de donnes. Le temps de calibrage ncessaire
pour le site complet est denviron 15 minutes (150 * 6 = 900 secondes soit 15 minutes).
Pour faire le calibrage, le portable sur lequel tourne le logiciel Ekahau Manager (ou ESS) est
dpos au point o on veut relever un chantillon. On clique sur le point correspondant sur la
carte du site dans Ekahau pour enregistrer ce point chantillon dans la base de donnes (dans
lEkahau Engine install dans notre cas sur le mme portable que lEkahau Manager).

Universit Paris-Est
10 m
AP2
AP1 PP1
DEST
AP7
PPs non calibrs
Points chantillons
chaque 4m (pas de AP3
la grille = 4m)
PP2
AP8
AP6
AP5
AP4 PP3
PP4
Figure 38- Scnario de base: calibrage uniforme
4.5.3.2 Positionnement et rsultats de prcision
Dans cette phase on cherche localiser des agents mobiles (on rappelle quon utilise
cette expression pour dsigner les objets mobiles (PC ou PDA) disposant du logiciel client et
que lon souhaite positionner) et dterminer la prcision de localisation. Les agents sont
dposs des endroits prcis du site (donc ils ne sont pas en mouvement mais on change leurs
positions chaque mesure).
On appelle par Prcision la diffrence en distance entre la position relle de lagent localiser
et sa position calcule par Ekahau. Elle est calcule comme suit : lagent est dpos en une
position donne et ses coordonnes cartsiennes (x , y) sont releves. Le logiciel de
positionnement Ekahau retourne aussi les coordonnes de lagent localis (ces coordonnes sont
exprimes en nombre de pixels mais comme la correspondance pixels/mtres du site considr
est configure sur Ekahau, on peut facilement calculer les coordonnes en mtres). Supposons
que x et y sont les coordonnes relles de lobjet et x et y les coordonnes de lobjet estimes
par Ekahau, on peut dduire la diffrence en distance ou encore la prcision comme suit :
Cette prcision est calcule pour chaque position de lagent, puis la moyenne de toutes les
prcisions (obtenues des diffrentes positions) est calcule (cest cette moyenne qui sera note
dans les tableaux de rsultats qui suivent).
Nous avons mesur cette prcision soit directement sur la carte affiche lcran du PC soit en
la mesurant avec une mtre sur le site rel.

Universit Paris-Est
Dans le scnario de base (scnario 1) qui utilise la mthodologie de calibration uniforme

on a observ que la prcision est presque la mme pour tous les dispositifs localiser. On
localise chaque agent dans 50 endroits diffrents (ces endroits sont alatoires et ne sont pas
situs uniquement sur les points de la grille de la figure 38 l o les points chantillons ont t
relevs) avant de passer localiser un autre agent (dans dautres positions qui ne sont pas
toujours les mmes que pour lagent prcdent).
Pour chaque position, la mesure est effectue sur 1 minute. Cest--dire quEkahau peut
moyenner les estimations de position pendant 1 minute ce qui permet de diminuer la variance de
cette estimation. En effet le serveur de positionnement Ekahau calcule une estimation de
position de faon priodique. La dure minimale de cette priode dpend du temps de calcul du
serveur positionnement, de la vitesse de balayage du chipset WiFi du client agent, de la qualit
de la liaison radio qui affecte la vitesse avec laquelle les mesures des RSSI sont reues par le
serveur. Par exemple si la vitesse de balayage du chipset WiFi de lagent mobile est de
1 seconde, alors la position de lagent est actualise une fois par seconde par le serveur de
positionnement ; le temps ncessaire pour effectuer lensemble des mesures sur les 50 positions
diffrentes a t denviron une heure.
Voici un tableau rcapitulant les rsultats de prcision de ce scnario:
Agent Logiciel Adapteur WiFi Prcision moyenne

sur le site (3)
Ordinateur Windows 2000 Cisco Aironet 802.11a/b/g Cardbus 0.6 m (0.28 m)
portable Adapter
Ordinateur Windows XP 3Com OfficeConnect Wireless 0.65 m (0.30 m)
portable 11a/b/g PC Card
i-mate JAM Windows Mobile SDIO Wireless 11Mbs Adapter for 0.5 m (0.17 m)
2003 Second PDA imate Jam XDA mini 802.11g
Edition
i-mate JASJAM Windows Mobile WiFi IEEE 802.11b/g internal 0.6 m (0.25 m)
5.0 WLAN antenna
Table 16- Rsultats de prcision moyenne pour le scnario de base
On montre dans le tableau 16 les rsultats de localisation de quatre agents : deux PCs
portables et deux ordinateurs de poche de type i-mate. Les rsultats des tests ont montr que la
prcision tait meilleure sur les points de la grille, c..d quand les clients agents sont placs
exactement l o les points chantillons ont t enregistrs lors de la phase de calibrage. Le
troisime agent du tableau tait plac sur les points de la grille, et par suite la prcision de sa
localisation est la meilleure. Pour ce mme agent plac en dehors des points de la grille, la
prcision tait aux alentours de 0.6m (semblable celle de lagent i-mate JASJAM). On peut
dire que les diffrences de prcision obtenues ne dpendaient pas des cartes matrielles wifi
intgres dans les objets mais plutt des positions des objets.
4.5.3.3 Impact de la mobilit sur la prcision
On a aussi tudi dans ce scnario, limpact de la mobilit du dispositif localiser sur la

prcision.
3
Valeur de lcart-type

Universit Paris-Est
Au passage du dispositif sur les positions indiques pour la mesure de prcision, les coordonnes
retournes par Ekahau sont notes. A la fin de lexprimentation, la moyenne de prcision pour
toutes les positions a t calcule.
Une personne (quon appellera la personne 1) tenait le PDA ou PC portable localiser (sur
lequel tournait le client agent) et se dplaait tout au long du site une vitesse denviron 2 km/h,
ce qui correspond un pas de lordre de 50 cm par seconde. Le trajet que devait effectuer cette
personne tait prdfini : on lavait marqu sur le sol avec une craie. On avait indiqu sur ce
trajet les 70 positions o lon devait retenir les positions estimes par Ekahau. La forme de ce
trajet est montre sur la figure 39 suivante :
Figure 39- Trajet effectu pour l'tude de l'impact de la mobilit sur la prcision de
localisation
Une deuxime personne tait installe devant le PC disposant du logiciel EPE de calcul de
positions. Elle pouvait voir la personne 1 se dplacer rellement sur le site. Lorsque la personne
1 arrivait sur les positions indiques pour la mesure de prcision, les coordonnes retournes par
Ekahau taient notes. A la fin de chaque test, on effectuait les calculs de la prcision pour
chacune des positions.
La moyenne de la prcision obtenue pour une distance de 50 mtres (parcourue pendant une
dure de 90 secondes) est calcule. On note dans le tableau 17 la prcision obtenue avec un
ordinateur portable et un i-mate :

Universit Paris-Est
Agent Logiciel Adapteur WiFi Prcision moyenne (4)

Ordinateur Windows 2000 Cisco Aironet 0.95 m (0.72 m)
portable 802.11a/b/g Cardbus
Adapter
i-mate JAM Windows Mobile SDIO Wireless 11Mbs 0.9 m (0.7 m)
2003 Second Edition Adapter for PDA imate
Jam XDA mini 802.11g
Table 17- Impact de la mobilit sur la prcision dans le scnario 1
Plusieurs facteurs principaux peuvent influencer la prcision obtenue en mobilit. Un premier

facteur est lorientation du dispositif localiser. On avait en effet remarqu en mode statique que
la prcision tait meilleure pour les positions o le dispositif tait pos dans la mme orientation
que celle de lordinateur utilis pendant le calibrage ; Un deuxime facteur est la prsence de la
personne qui portait le dispositif pour les tests en mobilit. La personne qui tenait le dispositif
pouvait influencer sur les puissances des signaux reus des diffrents APs (son corps pouvait en
quelque sorte attnuer les signaux des APs). Il aurait t intressant de faire dplacer le dispositif
sur un support tlguid par exemple, mais ceci na pas pu tre mis en uvre dans le cadre de
cette exprimentation. Dautre part, le logiciel EPE ne peut pas moyenner les estimations de
position pendant une dure dune minute comme dans le cas des tests en mode statique. Enfin,
des tudes ont montr que pour les rcepteurs WiFi qui sont en mouvement, les puissances des
signaux reus des APs prsentent une variance plus grande que lorsquils ne sont pas en
mouvement [53] et que cette caractristique pouvait tre utilise pour dterminer si un piton
tait larrt ou en dplacement.
4.5.4 Scnario propos (scnario 2) - RAMPE/INFOMOVILLE RWPS

4.5.4.1 Mthodologie de calibration
Le but de ce 2me scnario est de renforcer la prcision dans certains endroits du site
prcisment sur les PPs, les chemins privilgis que la personne peut emprunter pour aboutir la
destination, tout en ayant, en dehors des PPs, une ide sur la position globale de la personne (
gauche du PP, sa droite, etc) ; ceci va nous permettre, dans les scnarios de guidage dtaills
ultrieurement dans ce chapitre, de localiser la personne sur le site puis de la ramener sur un PP
afin de le guider travers ce PP vers la destination. On montre dans cette section, les
performances de cette technique baptise RAMPE/INFOMOVILLE WiFi Positioning System
(RWPS).
Pour ce faire, les points chantillons ont t mesurs sur chaque PP en prenant un
chantillon tous les 0.4 mtres. On prend donc 6 chantillons en largeur du PP (2.4 m/0.4 m =6
chantillons), puis on sloigne de 0.4 m sur le PP et on prend de nouveau 6 autres chantillons
en largeur. Pour un PP de longueur 50 m, on obtient ainsi environ 750 chantillons. La mesure
de chaque chantillon a t effectue en environ 6 secondes. Il faut donc de lordre de 75
minutes pour relever lensemble de ces chantillons sur un PP. Nous avons calibr 4 PPs. Il a
fallu entre 5 et 6 heures pour effectuer le calibrage complet sur les 4 PPs. Sur le reste du site, les
chantillons sont pris, comme pour le scnario 1, en raison dun chantillon tous les 4 mtres
pour la longueur et la largeur du site. On obtient donc aux alentours de 150 chantillons en total.
4

Universit Paris-Est
Et en effectuant chaque mesure en 6 secondes, il faut environ 15 minutes pour calibrer le reste
du site.
Figure 40- RWPS : calibrage fin sur les PPs
4.5.4.2 Rsultats de prcision
Durant la phase de localisation, on a remarqu que la prcision est meilleure sur les PPs
que partout sur le reste du site, ce qui nous a permis de localiser les clients globalement sur le
site mais en arrivant sur les PPs la prcision devient de lordre de 20 cm. La mthode de calcul
de prcision est la mme que dans le premier scnario : les diffrents dispositifs localiser sont
placs en 50 positions diffrentes du site (parfois sur les points de la grille), et la moyenne de la
prcision est calcule pour ces 50 positions ; de mme sur les PPs, 50 positions diffrentes ont
t choisies. Les mesures dans ce cas ont dur environ deux heures par dispositif (une heure
pour le positionnement sur le site et une heure pour le positionnement sur les PPs).
Le tableau 18 rcapitule les rsultats obtenus:
Agent Logiciel Adapteur WiFi Prcision Prcision

moyenne sur moyenne hors
les PP (5) des PP (6)
Ordinateur Windows 2000 Cisco Aironet 0.2 m (0.13 m) 0.6 m (0.28 m)
Adapter
5
6

Universit Paris-Est
Ordinateur Windows XP 3Com OfficeConnect <0.2 m (0.12 0.65 m (0.30 m)

portable Wireless 11a/b/g PC m)
Card
i-mate JAM Windows Mobile SDIO Wireless 11Mbs <0. 2m (0.12 0.5 m (0.17 m)
2003 Second Adapter for PDA imate m)
Edition Jam XDA mini 802.11g
i-mate JASJAM Windows Mobile WiFi IEEE 802.11b/g <0.2 m (0.12 0.6 m (0.25 m)
5.0 internal WLAN antenna m)
Table 18- Performances en prcision de RWPS
4.5.4.3 Rflexions
Si lon dsirait avoir la mme prcision que celle obtenue sur les PPs partout sur le site,
on devrait calibrer tout le site de la mme manire que les PPs, ce qui demanderait peu prs
26 heures de calibration. En effet, raison dun chantillon tous les 0.4 mtres, sur 50 m de
longueur et 50 m de largeur, on obtient 15,625 chantillons pour tout le site et comme chaque
chantillon demande 6 secondes, il faut environ 26 heures. On a minimis ce temps en
renforant la prcision seulement dans certains endroits spcifiques du site qui sont les PPs.
4.5.4.4 Impact de la mobilit sur la prcision
Comme dans le scnario 1, on a test dans ce scnario limpact de la mobilit du

dispositif localiser sur la prcision. Le mme type de dmarche que dans le scnario 1 a t
adopte : une personne tenait le dispositif et se dplaait sur un trajet prdfini une vitesse de
lordre de 2 km/h, puis dans un 2me temps elle se dplaait sur lun des PPs finement calibrs ;
la prcision est calcule pour 70 positions au total sur chaque trajet. Les trajets effectus en
dehors des PPs et sur un PP sont montrs dans la figure 41.

Universit Paris-Est
Figure 41- Trajets effectus pour l'tude de l'impact de la mobilit sur la prcision de
localisation
Agent Logiciel Adapteur WiFi Prcision sur Prcision hors

Ordinateur Windows 2000 Cisco Aironet 0.3 m (0.26 m) 0.95 m (0.72 m)
Adapter
i-mate JAM Windows Mobile SDIO Wireless 11Mbs 0.3 m (0.26 m) 0.9 m (0.7 m)
2003 Second Adapter for PDA imate
Edition Jam XDA mini 802.11g
Table 19- Impact de la mobilit sur la prcision dans le scnario 2
Les mmes facteurs que ceux prsents pour le scnario 1 influencent sur la prcision obtenue
en mobilit de ce scnario.
4.5.5 Scnarios de modifications et de perturbations

Lune des contraintes dexploitation du systme de localisation et de guidage bas sur les
ondes WiFi et la mthode dempreinte radio, concerne les ventuelles perturbations ou
modifications que peuvent subir les lments de cette mthode. Par exemple, on peut changer la
position des points daccs suite des travaux, ou bien certains APs peuvent tomber en panne,
7
8

Universit Paris-Est
de nouvelles constructions peuvent apparatre, ... Ce qui peut modifier la carte radio du site et
par suite influencer les calculs de positions.
On prsente dans ce paragraphe les exprimentations qui ont t ralises pour valuer
limpact sur la prcision, de quelques perturbations sur linfrastructure du site de test principal.
On essaie dtudier la capacit du systme rester fonctionnel (c'est--dire fournir des
informations de localisation correctes) mme quand une partie des quipements est hors-service.
Trois scnarios ont t tudis et sont dtaills dans les paragraphes suivants.
4.5.5.1 Scnario 3 - Elimination de quelques APs avant le calibrage
On tudie dans ce scnario la prcision du systme en fonction du nombre dAPs mis en

service. Le mme site que dans les tests prcdents a t calibr mais avec moins dAPs.
4.5.5.1.1 Mthodologie de calibration
Dans ce scnario, lAP3, lAP5 et lAP7 ont t dbranchs ds le dbut (simulation du

cas o il y a moins dAPs dans le site). Le calibrage a donc t fait avec 5 APs seulement : AP1,
AP2, AP4, AP6 et AP8, avec le mme principe que celui du scnario 2: calibrage fin sur les PPs
et uniforme hors des PPs.
Figure 42- Calibrage avec moins dAPs

Universit Paris-Est
4.5.5.1.2 Rsultats de prcision
Dans ce scnario, la prcision a vari par rapport celle du scnario 2 comme le montre
le tableau suivant:
Agent Logiciel Adapteur WiFi Prcision sur les Prcision

PP (9) hors des PP
(10)
Ordinateur Windows 2000 Cisco Aironet 0.35 m (0.14 m) <0.95 m(0.29
portable 802.11a/b/g Cardbus m)
Adapter
Ordinateur Windows XP 3Com OfficeConnect <0.35 m (0.14 m) <0.95 m (0.29
portable Wireless 11a/b/g PC m)
Card
i-mate JAM Windows Mobile SDIO Wireless 11Mbs <0.3 m (0.14 m) <0.85 m (0.19
2003 Second Adapter for PDA m)
Edition imate Jam XDA mini
802.11g
i-mate JASJAM Windows Mobile WiFi IEEE 802.11b/g <0.3 m (0.14 m) ~ 0.9 m (0.28
5.0 internal WLAN m)
antenna
Table 20- Elimination dAPs pendant le calibrage
Dans ce scnario, certains points du site recevaient le signal de moins de 3 APs, ce qui a
diminu la prcision par rapport au scnario 2. Lerreur absolue a augment en moyenne de 32
cm en dehors des PPs et de 12 cm sur les PPs, ce qui reprsente une variation relative de
respectivement 55% et 62%.
4.5.5.2 Scnario 4 Suppression dAPs pendant le positionnement
Dans ce scnario, le calibrage du site est fait de la mme faon que pour le scnario 2 : 8
APs utiliss durant le calibrage, avec un calibrage fin sur les PPs. Mais, pendant la phase de
positionnement, lAP3, lAP5 et lAP7 ont t dbranchs (simulation du cas o les APs
tombent en panne pendant le positionnement (Figure 43)).
9
10

Universit Paris-Est
Figure 43- APs en panne pendant le positionnement
4.5.5.2.2 Rsultats de prcision
Agent Logiciel Adapteur WiFi Prcision sur Prcision hors

Ordinateur Windows 2000 Cisco Aironet 0.25 m (0.13 m) ~ 0.7 m (0.29
portable 802.11a/b/g Cardbus m)
Adapter
Ordinateur Windows XP 3Com OfficeConnect <0.25 m (0.13 <0.75 m (0.29
portable Wireless 11a/b/g PC m) m)
Card
i-mate JAM Windows Mobile SDIO Wireless 11Mbs <0.25 m (0.13 <0.6 m (0.18
2003 Second Adapter for PDA imate m) m)
Edition Jam XDA mini
802.11g
i-mate JASJAM Windows Mobile WiFi IEEE 802.11b/g <0.2 m (0.13 ~ 0.7 m (0.28
5.0 internal WLAN m) m)
antenna
Table 21- APs en panne pendant le positionnement
On remarque que la prcision na pas beaucoup vari par rapport au scnario 2 surtout sur les
PPs o le calibrage tait fin. La carte radio avait t construite avec 8 APs fonctionnant
simultanment. Lerreur absolue a augment en moyenne de 10 cm en dehors des PPs et de 4 cm
sur les PPs, ce qui reprsente une variation relative infrieure 20% dans les deux cas.
11
12

Universit Paris-Est
On constate donc que la panne des APs a moins dinfluence sur la prcision quand elle se
produit pendant la phase de localisation que pendant la phase de calibrage. Dans les deux cas, la
variation relative de la prcision est similaire en dehors et sur les PPs, mais la variation absolue
est bien sr plus faible pour les PPs.
4.5.5.3 Scnario 5 - Dplacement des APs
Dans ce scnario, aprs avoir calibr tout le site avec les 8 APs disposs comme dans le
scnario 2, avec un calibrage fin sur les PPs, on a dplac ces points daccs afin dtudier
leffet de ce dplacement sur la prcision de localisation. On a commenc par dplacer un seul
AP, puis 2 APs la fois et enfin 3 APs.
Considrons lAP1; on montre dans la figure 44 suivante sa position initiale et sa position aprs
dplacement.
Figure 44- Dplacement dun seul AP pendant la phase de positionnement
La nouvelle position de lAP1 est maintenant loigne de la position initiale de 1 m

horizontalement. En adoptant la mme mthode de calcul de prcision (les diffrents clients
agents sont mis en 50 positions diffrentes du site (parfois sur les points de la grille), et en 50
positions sur les PPs, et la moyenne de la prcision est calcule pour ces 50 positions), cette
prcision na pas chang pour les positions sur les PPs de mme que pour les positions hors des
PPs. Pour un dplacement de 1,5 m, la prcision a vari : elle devient en moyenne de 0.3 m sur
les PPs et 0.8 m en dehors des PPs ; pour un dplacement de 2 m, elle varie davantage ; elle
devient en moyenne de 0.4 m sur les PPs et 0.9 m en dehors des PPs) ; elle continue varier au
fur et mesure quon dplace davantage lAP1. Le tableau 22 regroupe tous les rsultats
obtenus pour un dplacement dun seul AP pendant le positionnement :

Universit Paris-Est
Valeur du Agent Logiciel Adapteur WiFi Prcision Prcision

dplacement sur les PP hors des
des AP PP
Ordinateur Windows XP 3Com OfficeConnect 0.3 m 0.8 m
portable Wireless 11a/b/g PC
Card
1.5 mtres i-mate JAM Windows SDIO Wireless 11Mbs 0.3 m 0.75 m
Mobile 2003 Adapter for PDA imate
Second Jam XDA mini
Edition 802.11g
Card
2 mtres i-mate JAM Windows SDIO Wireless 11Mbs 0.4 m 0.9 m
Second Jam XDA mini
Edition 802.11g
Card
Second Jam XDA mini
Edition 802.11g
Card
Second Jam XDA mini
Edition 802.11g
Table 22- Dplacement d'un AP pendant le positionnement
Avec 2 points daccs dplacs la fois, lAP1 et lAP5 (cf. figure 45), la prcision commence
varier ds le premier mtre de dplacement horizontal des 2 APs (0.35 m de prcision sur les
PPs et 0.9 m en dehors des PPs).
AP1 est toujours dplac de 1 m, et on dplace AP5 de 2 m : la prcision est de 0.65 m sur les
PPs et de 1.4 m en dehors des PPs.
Le tableau 23 suivant regroupe les rsultats obtenus avec un dplacement de 2 APs pendant le
positionnement :
Valeur du Agent Logiciel Adapteur WiFi Prcision Prcision

dplacement sur les PP hors des
de lAP PP
Card
1 mtre i-mate JAM Windows SDIO Wireless 11Mbs 0.35 m 0.9 m
Second Jam XDA mini
Edition 802.11g

Universit Paris-Est

2 mtres portable Wireless 11a/b/g PC
(AP1 Card
dplac de 1 i-mate JAM Windows SDIO Wireless 11Mbs 0.65 m 1.4 m
m et AP5 de Mobile 2003 Adapter for PDA imate
2 m) Second Jam XDA mini
Edition 802.11g
Ordinateur Windows XP 3Com OfficeConnect 1m 1.9 m
Card
5 mtres i-mate JAM Windows SDIO Wireless 11Mbs 1m 1.9 m
Second Jam XDA mini
Edition 802.11g
Ordinateur Windows XP 3Com OfficeConnect 1.8 m 3m
Card
10 mtres i-mate JAM Windows SDIO Wireless 11Mbs 1.8 m 3m
Second Jam XDA mini
Edition 802.11g
Table 23- Dplacement de 2 APs pendant le positionnement
Figure 45- Dplacement de 2 APs pendant la phase de positionnement
La situation saggrave avec le dplacement de 3 points daccs dplacs la fois: lAP1, lAP5
et lAP8 (cf. figure 46) ; la prcision commence varier ds le 1er mtre de dplacement des 3

Universit Paris-Est
APs. Les rsultats nots dans le tableau 24 reprsentent les prcisions de localisation obtenues
suite un dplacement de 3 APs de 10 mtres chacun :
Agent Logiciel Adapteur WiFi Prcision Prcision

sur les PP hors des
PP
Ordinateur Windows XP 3Com OfficeConnect Wireless 2.2 m 3.8 m
portable 11a/b/g PC Card
i-mate JAM Windows Mobile SDIO Wireless 11Mbs Adapter 2.2 m 3.8 m
2003 Second for PDA imate Jam XDA mini
Edition 802.11g
Table 24- Dplacement de 3 APs de 10 mtres
10 m
AP2
AP1
DEST
PP1
Points chantillons PPs calibrs AP7

chaque 4m finement
AP3
PP2
AP6
AP5
AP4 PP3
PP4 AP8
Figure 46- Dplacement de 3 APs pendant la phase de positionnement
La prcision est beaucoup dgrade, mais malgr un dplacement de 10 m pour 3 APs, on

conserve une prcision infrieure 4 m car il reste encore 5 APs bien positionns sur une
surface de 50 m x 50 m.
On peut noter que la diffrence de prcision entre les points en dehors des PPs et sur les PP tend
sattnuer, mme si elle reste meilleure sur les PPs.
En comparant les rsultats obtenus avec 3 APs en panne et 3 APs dplacs de 10 m chacun
pendant la localisation, on remarque que les rsultats sont beaucoup plus dgrads dans le
deuxime cas. Lorsque lon dplace des APs, il vaut mieux les teindre que de les laisser
fonctionner.
Dans le cas de dplacement important des APs, un recalibrage du site doit tre effectu pour
maintenir la prcision de localisation. Cest lune des contraintes considrer dans lexploitation
du systme.

Universit Paris-Est
4.6 Guidage dans les diffrents scnarios

On expose dans ce paragraphe le travail effectu pour analyser leffet de la prcision de
localisation sur le guidage. Les tests de guidage ont t effectus sur plusieurs personnes.
On reprend les diffrents scnarios des paragraphes prcdents. Dans chaque scnario, on essaye
de positionner la personne puis de la ramener sur le chemin privilgi le plus proche et de la
guider travers ce PP vers la destination.
La personne guide a les yeux ferms et ne connait pas le site ; elle porte le imate JAM sur
lequel tourne le client et tient dans sa main un interphone ; cet interphone lui permet dentendre
la personne Guide. La personne guide est installe dans un bureau derrire le site et donc
ne voit pas la personne guide mais visualise la position de li-mate sur le logiciel de
positionnement en temps rel. Elle doit guider la personne aux yeux ferms vers la destination
(note DEST sur les diffrentes figures) laide dun jeu limit de messages de guidage vocaux
qui seront prciss plus loin.
Les personnes guides navaient pas le droit de poser de questions lors de lexprimentation,
toutefois des interrogations se font parfois entendre : Comme a cest bon ?, suis-je sur le bon
chemin, etc . La personne guide pouvait entendre ces questions travers linterphone mais
elle ne rpondait pas ; elle se contentait dnoncer les consignes de guidage, prdfinies pour
cette exprimentation, et apprises la personne guide avant le test de guidage:
- Tu es gauche du PP ! et donc la personne sait quelle doit prendre sa droite en
avanant.
- Tu es droite du PP ! la personne sait quelle doit prendre sa gauche en avanant.
- Tu es sur le bon PP ! Avance! ce message est rpt tant que la personne est sur le
bon PP, intervalles rguliers (toutes les 20 25 secondes environ).
- Tourne droite ! la personne sait quelle doit tourner de 90 sa droite.
- Tourne gauche ! la personne sait quelle doit tourner de 90 sa gauche.
- Tourne de 45 ta gauche et avance .
- tourne de 45 ta droite et avance! .
ct de la personne guide, une autre personne relve rgulirement des estimations de postion
donnes par le logiciel Ekahau.
Une dernire personne se trouvant proximit de la personne guide, notait sur le sol la craie
certains des points du trajet rel effectu par la personne guide ; la fin de chaque test les
coordonnes (x,y) de ces points ont t mesures et sauvegardes.
noter que la personne guide pouvait atteindre la destination sans avoir changer le sens de
son trajet (pas de dtour), cest--dire en restant toujours dirige dans la direction de la
destination (sauf si elle se perdait) ; Aussi le message tourne dans le sens oppos na-t-il pas
t inclus dans la liste des messages, La connaissance de lorientation des personnes nest pas
considre dans le contexte de cette exprimentation (le Personal Guidance System propos par
Jack Loomis, Reginald Golledge et Roberta Klatzky [49] aborde des consignes de guidage
spcifiques au systme quils proposent et qui consiste guider des personnes aux yeux ferms
sur des routes prdfinies; ce systme est bas sur la localisation GPS et lorientation des
personnes est dtecte grce un compas de type fluxgate compass qui fournit le cap
magntique et qui peut tre port sur la tte).
4.6.1 Guidage dans le scnario de calibrage uniforme (scnario 1)

Dans ce scnario, dix personnes (UM- Utilisateur Mobile) ont t guides. On montre
dans la figure 47, dune part le trajet rel effectu par lUM (avec des marqueurs en forme de +

Universit Paris-Est
ou en format gras) et dautre part le trajet calcul par Ekahau (avec des marqueurs en forme de
disque plein ou en pointill). Chaque marqueur reprsente un point de mesure et on a interpol
linairement entre ces marqueurs pour le trac. On donne 2 versions de la figure ; une premire
version avec un trac lchelle en indiquant sur chaque trac les points de mesure relevs. Il est
noter quil ny a pas de synchronisation temporelle entre les points de mesure sur les tracs
rels et les tracs Ekahau. Une deuxime version plus schmatique (pas lchelle) rappelant les
positions des points daccs. Les mmes conventions seront utilises pour les figures 47 52. Le
point de dpart ntait pas le mme pour toutes les personnes (ce point se trouve l o est
dessine la personne malvoyante). La table 25 donne le temps mis par chaque personne pour
aboutir la destination (temps depuis le reprage de la position de lUM jusqu son arrive la
destination).
Il a t possible de conduire les dix personnes vers un PP, mais cette premire tape a ncessit
un temps assez diffrent dun UM lautre. De plus, certains UM ont parfois suivi un autre PP
que celui que le guide dsirait vraiment (cas dUM3, dUM9 et dUM10) ; parfois, alors que le
guide essayait de mettre une personne sur le bon PP, cette personne a heurt un obstacle se
trouvant au milieu du site (cas dUM2 heurtant un bac fleurs) ; le virage trop serr du PP4 qui
prsente quatre angles 90 rapprochs (cercl sur la figure 47) na pas t suivi par UM5.
Parfois la personne se trouve rellement sur un PP tandis que sur le systme Ekahau la dtecte
hors chemin et vice-versa. La prcision de localisation du piton en mouvement est infrieure
celle obtenue avec les tests dcrits prcdemment car la personne ne cherche pas maintenir une
vitesse de dplacement lente et rgulire. On observe sur les diffrents tracs que les distances
entre les positions estimes et relles sont souvent de lordre de 3 m (au lieu de 0,9 m dans le
tableau 17). si par exemple la position estime par Ekahau est sur le PP, la personne guide va
noncer le message de Tu es sur le bon chemin; Avance!; tandis quen ralit la personne se
trouve hors du PP et de cette faon elle va continuer savancer hors du PP. Linverse est aussi
vrai : la position estime par Ekahau est hors du PP ( gauche de celui-ci). La personne guide va
noncer : Tu es gauche du PP! ; tandis que cette personne se trouve rellement sur le PP,
elle va aller sa droite et sortir du PP.

Universit Paris-Est
UM8
DEST
5
10
UM1
15
UM3 UM10
UM2
20
y (mtres)
25
UM9
30
35
UM4
40
45
UM6
UM5
UM7
50
0 5 10 15 20 25 30 35 40 45 50
x (mtres)
Figure 47- Guidage dans le scnario de calibrage uniforme

Universit Paris-Est
Utilisateur Preferred Path Distance la destination Temps pour arriver la

Mobile au dmarrage13 destination
UM1 PP1 46 m 5 minutes 10 secondes
UM2 PP2 61 m 6 minutes
Table 25- Temps de guidage dans le scnario de calibrage uniforme
Daprs le tableau 25, on peut dduire la vitesse de la personne guide qui est infrieure
1 km/h. Le temps de guidage est affect par les nombreuses oscillations qua subi le trajet rel de
la personne ; Les consignes de guidage dans ce scnario ont t frquentes, ce qui perturbait en
quelque sorte la personne guide. UM7 par exemple ne cessait de demander ce quil devait faire:
maintenant gauche, maintenant quoi ?....
4.6.2 Guidage dans le scnario de RWPS (scnario 2)
Parmi les 10 personnes qui ont particip ce nouveau test, deux avaient dj effectu le
test pour le scnaio 1 : UM7 (PP2) et UM10 (PP4). Mais pour le scnario RWPS elles ont t
guides sur des chemins diffrents (PP1 et PP3). Pour ce nouveau scnario, elles sont notes
respectivement UM1 (PP1) et UM6 (PP3).
13
Cette distance correspond un trajet sur un PP plus la distance pour aboutir ce PP

Universit Paris-Est
UM8
DEST
5
10
UM1
15
UM3 UM10
UM2
20
y (mtres)
25
UM9
30
35
UM4
40
45
UM6
UM5
UM7
50
0 5 10 15 20 25 30 35 40 45 50
x (mtres)
Figure 48- Guidage utilisant RWPS

Universit Paris-Est
Utilisateur Preferred Path Distance la Temps pour arriver la

Mobile destination au destination
dmarrage
Table 26- Temps de guidage dans RWPS
On constate que la dure moyenne pour guider les personnes jusqu la destination est infrieure
celle du scnario1 (environ 2 fois plus courte).
Ds que lUM atteint rellement un PP (entre dans la zone du PP), le logiciel de positionnement
peut le localiser avec une bonne prcision et le guidage peut ensuite seffectuer sans beaucoup
doscillations jusqu la destination.
Afin de pouvoir rsoudre le problme rencontr dans le cas du scnario 1, pour le virage du PP4
(voir la zone cercle de la figure 48 (la personne guide continuait tout droit son chemin sans
suivre le PP)), des chantillons supplmentaires ont t relevs sur le contour du PP4 et dans la
zone du virage raison dun chantillon tous les 0.2 ou 0.3 m, ce qui a permis une prcision de
lordre de 0,1m dans cette rgion.
4.6.3 Guidage dans le scnario dlimination dAPs avant le calibrage

Comme la fois prcdente, 3 APs ont t dbranch (AP3, AP5 et AP7) ds la phase de
calibrage.
Les tests ont t raliss sur trois personnes. La figure 49 illustre les trajets parcourus et estims.
La table 27 prcise les rsultats obtenus en termes de dure.

Universit Paris-Est
UM1
DEST
5
10
15
UM2
20
y (mtres)
25
30
35
40
45
UM3
50
0 5 10 15 20 25 30 35 40 45 50
x (mtres)
Figure 49- Guidage dans le scnario de suppression dAPs avant le calibrage

Universit Paris-Est

dmarrage
Table 27- Temps de guidage dans le scnario dlimination dAPs avant le calibrage
On observe une dgradation significative de la prcision du positionnement quand on nutilise

que 5 APs au lieu de 8.
4.6.4 Guidage dans le scnario de suppression dAPs pendant le

positionnement
Dans cette exprimentation, les 8 APs ont t utiliss pour le calibrage puis 3 APs ont t
dbranchs pendant la phase de localisation (AP3, AP5 et AP7).
Les tests ont t raliss sur trois personnes. La figure 50 illustre les trajets parcourus et estims.
La table 28 prcise les rsultats obtenus en terme de dure.
UM1
DEST
5
10
15
UM2
20
y (mtres)
25
30
35
40
45
UM3
50
0 5 10 15 20 25 30 35 40 45 50
x (mtres)

Universit Paris-Est
Figure 50- Guidage dans le scnario de suppression dAPs pendant le positionnement
Utilisateur Preferred Path Distance la Temps pour arriver

Mobile destination au la destination
dmarrage
Table 28- Temps de guidage dans le scnario de suppression d'APs pendant le
positionnement
Dans ce scnario, les rsultats sont assez proches de ceux obtenus avec les 8 APs pendant la
localisation. Les chemins semblent cependant un peu moins rectilignes.
4.6.5 Guidage dans le scnario de dplacement des APs

Dans un premier test, on dplace un seul AP (AP1) de 20 mtres. Les tests ont t
raliss sur trois personnes. La figure 51 illustre les trajets parcourus et estims. La table 29
prcise les rsultats obtenus en termes de dure.

Universit Paris-Est
UM1
DEST
5
10
15
UM2
20
y (mtres)
25
30
35
40
45
UM3
50
0 5 10 15 20 25 30 35 40 45 50
x (mtres)
Figure 51- Guidage dans le scnario de dplacement d'un AP (de 20 mtres)

Universit Paris-Est

dmarrage
UM1 PP1 42 m (na pas abouti au bout dune
dure de 2 minutes 55
secondes)
Table 29- Temps de guidage dans le scnario de dplacement dun AP (de 20 mtres)
On constate que la prcision de localisation sest beaucoup dgrade. Mme si il a t possible

de guider 2 des 3 personnes jusqu destination.
On a ensuite dplac 2 APs de 20 mtres (AP1 et AP5). Les rsultats sont prsents sur la figure
52 et la table 30. Ils sont comparables ceux du test prcdent.
UM1
DEST
5
10
15
UM2
20
y (mtres)
25
30
35
40
45
UM3
50
0 5 10 15 20 25 30 35 40 45 50
x (mtres)

Universit Paris-Est
UM1 10 m AP2
AP1
DEST
PP1
PPs calibrs AP7

finement
AP3
UM2 PP2
AP8
AP6
AP5
AP4
PP3 UM3
PP4
Figure 52- Guidage dans le scnario de dplacement de 2 APs (de 20 mtres)

dmarrage
UM1 PP1 42 m (na pas abouti au bout
dune dure de 2 minutes 50
secondes)
Table 30- Temps de guidage dans le scnario de dplacement de 2 APs
4.6.6 RSSI durant le guidage

Pendant le guidage des personnes (des UMs) on a relev les RSSI reus par limate
JAM port par lUM. Cette mesure est donne par le logiciel de positionnement EPE
dEkahau14. Les valeurs sont indiques pour chaque canal radio (sur lequel opre chaque AP) et
sont comprises entre -100 et 0, -100 correspondant au RSSI minimum et 0 au RSSI maximum.
Ce sont des valeurs indicatrices sans unit.
On trace sur les figures suivantes, les valeurs des RSSI relevs pour chaque client agent lors de
son dplacement. Ces valeurs sont prises des instants spcifiques dans lintervalle [0-280
secondes] pour le scnario 1 avec un pas de 20 secondes, et dans lintervalle [0-140 secondes]
pour le scnario 2 de RWPS avec un pas de 10 secondes (15 valeurs de RSSI de chaque AP ont
t notes; mais comme le temps de guidage dans le scnario 1 est suprieur celui du scnario
14
Il suffit de faire un Show RSSI en slectionnant, sur le logiciel de positionnement EPE, lagent i-mate
positionn, et en faisant un clic droit sur son adresse MAC.

Universit Paris-Est
2, on a relev une valeur toutes les 20 secondes pour le scnario 1 et une valeur toutes les10
secondes pour le scnario 2) ; chaque courbe reprsente les mesures reues dun point daccs (8
courbes pour 8 APs).
0 0
AP1
-10 UM1 AP2 -10 UM2
AP3
-20 -20
AP4
AP5 -30
-30
AP6
-40 AP7 -40
RSSI (dbm)
AP8
-50 -50
-60 -60
-70 -70
-80 -80
-90 -90
-100
-100
0 50 100 150 200 250 300 0 50 100 150 200 250 300
temps (secondes) temps (secondes)
Figure 53- UM1 et UM2 durant le guidage du scnario de base (scnario n1)
La valeur du RSSI pour un AP donn, diminue quand lUM sloigne de cet AP et inversement.
Le PDA peut rcuprer les signaux des 8 APs lors de son dplacement et en mesurer la
puissance. En ignorant les faibles puissances (au-dessous de -80 par exemple), on a au moins les
signaux de 5 APs pour lUM1 et de 4 APs environ pour lUM2 qui participent sa localisation.
UM1 a pris un temps de 5 minutes 10 secondes pour aboutir la destination (cf. tableau 25 de ce
chapitre); linstant 280 secondes (4 minutes 40 secondes) de son trajet, il tait peu prs une
distance de 8 mtres (mesure rellement) de lAP2 et donc pouvait rcuprer le signal de lAP2
avec une puissance de -12 (voir graphe 1 de la figure 38 et figure 47 montrant le trajet effectu
par lUM1 dans le cas du scnario 1).
UM2 qui a pris 6 minutes pour aboutir la destination, se trouvait linstant 4 minutes 40
secondes peu prs une distance de 33 mtres de lAP2 (son trajet prsentait beaucoup
doscillations au dbut ; il a donc pris plus de temps que UM1 au dbut de ce trajet) et recevait
le signal de lAP2 avec une valeur RSSI de seulement -58.
0 0
AP1
-10 UM1 AP2 -10 UM2
AP3
-20 -20
AP4
-30 AP5 -30
AP6
RSSI (dbm)
-40 -40
AP7
-50 AP8 -50
-60 -60
-70 -70
-80 -80
-90
-90
-100
-100 0 20 40 60 80 100 120 140
0 20 40 60 80 100 120 140
temps (secondes)
temps (secondes)
Figure 54- UM1 et UM2 durant le guidage du scnario 2 (RWPS)

Universit Paris-Est
Comme pour le scnario 1, en ignorant les faibles puissances (RSSI au-dessous de -80 par
exemple), on reoit au moins les signaux de 5 APs pour UM1 et de 4 APs environ pour UM2 qui
participent sa localisation.
On vrifie quen moyenne les RSSI varient de faon cohrente par rapport la distance de la
personne par rapport aux points daccs.
UM1 a pris un temps de 2 minutes 42 secondes pour aboutir la destination (voir tableau 26 de
ce chapitre) ; linstant 140 secondes (2 minutes 20 secondes) de son trajet, il tait peu prs
une distance de 5 mtres de lAP2 et donc pouvait rcuprer le signal de lAP2 avec une
puissance de -9 voir graphe 1 de la figure 40 et figure 48 montrant le trajet effectu par lUM1
dans le cas du scnario 1).
Pour lUM2 qui a pris 2 minutes et 49 secondes pour aboutir la destination, linstant 2
minutes 20 secondes, il a rcupr le signal de lAP2 avec un RSSI de -40 et donc il tait encore
un peu loin de lAP2 (AP2 se trouve la destination) (un peu plus que 20 mtres).
On reprsente dans la figure 55 suivante les courbes des RSSI des 8 APs pour les diffrents
utilisateurs mobiles durant leur guidage dans le scenario RWPS.
0 0
AP1
-10 UM3 -10 UM4
AP2
-20 AP3 -20
AP4
-30 -30
AP5
RSSI (dbm)
-40 AP6 -40
-50 AP7 -50

AP8
-60 -60
-70 -70
-80 -80
-90 -90
-100 -100
0 20 40 60 80 100 120 140 0 20 40 60 80 100 120 140
0 0
AP1
-10 UM5 AP2 -10 UM6
-20 AP3 -20
AP4
-30 AP5 -30
-40 AP6 -40

RSSI (dbm)
AP7
-50 AP8 -50
-60 -60
-70
-70
-80
-80
-90
-90
-100
-100 0 20 40 60 80 100 120 140
0 20 40 60 80 100 120 140
temps (secondes)
temps (secondes)

Universit Paris-Est
0 0
AP1
-10 UM7 -10 UM8
AP2
AP3
-20 -20
AP4
-30 AP5 -30
AP6
-40 -40
RSSI (dbm)
AP7
-50 AP8 -50
-60 -60
-70 -70
-80 -80
-90 -90
-100 -100
0 20 40 60 80 100 120 140 0 20 40 60 80 100 120 140
0 0
AP1
-10 AP2 -10 UM10
UM9
-20 AP3 -20
-30 AP4
-30
AP5
RSSI (dbm)
-40 AP6 -40
-50 AP7 -50

AP8
-60 -60
-70 -70
-80 -80
-90 -90
-100 -100
0 20 40 60 80 100 120 140 0 20 40 60 80 100 120 140
Figure 55- RSSI des 8 APs pour les diffrents UM
4.6.7 Analyse
La prcision de localisation des dispositifs mobiles dans un systme de positionnement
utilisant les ondes radio WiFi et adoptant la technique dempreinte radio dpend de plusieurs
facteurs: le nombre dAPs utiliss durant le calibrage, leurs emplacements, le nombre
dchantillons pris et sauvegards dans la base de donnes, le changement des conditions
environnementales du site et ventuellement les caractristiques lectromagntiques, les cartes
WiFi des dispositifs, la mobilit des agents .
La solution propose dans ce chapitre (le scnario 2 appel RWPS), utilise une mthodologie de
calibration qui consiste prendre un grand nombre de points chantillons sur les chemins
prfrs et effectuer un calibrage plus grossier sur une grille uniforme pour le reste du site.
Ceci renforce la prcision sur les chemins prfrs, tout en vitant le temps important qui serait
ncessaire pour calibrer un site complet avec cette prcision. Le nombre des points daccs
participant au calibrage doit tre suffisant. Il est ncessaire dinstaller des APs dune faon
bien couvrir le site considr et recevoir le signal dau moins 3 APs en tout point du site. Tout
dplacement et/ou limination de points daccs pendant la phase de localisation peut rsulter en

Universit Paris-Est
des calculs de positions errons et dans ce cas le calibrage doit tre refait afin de reconstruire la
carte radio du site pour reflter ces changements. Ceci reste lun des problmes dans un tel
systme dempreinte radio et constitue une des perspective de travaux futurs pour cette thse.
Pour le guidage dans RAMPE/INFOMOVILLE, et daprs les exprimentations faites, RWPS a

montr une bonne fiabilit et efficacit (des trajets parcourus avec peu doscillations et des
temps de guidage infrieurs ceux du scnario 1). On tudie dans le paragraphe suivant la
possibilit dintgrer ce service de localisation et de guidage dans RAMPE/INFOMOVILLE.
4.7 Intgration dans RAMPE/INFOMOVILLE

Lintgration dun service de localisation et de guidage dans RAMPE/INFOMOVILLE
permettra de fournir aux utilisateurs du systme une assistance supplmentaire favorisant leur
mobilit et leur scurit en dplacement.
Diffrentes applications de localisation et ventuellement de guidage dun piton PAM sont
possibles (discuts dans le paragraphe 4.3). On considre le systme de localisation par ondes
WiFi et la mthode dempreinte radio ainsi que la solution propose dans le scnario 2 du
paragraphe 4.5 qui consiste adopter une mthodologie de calibration fine dans les zones
critiques afin de renforcer la prcision sur celles-ci (la mthode des chemins privilgis PPs
nomme RWPS).
Une application intressante sera de pouvoir localiser le PDA port par la PAM et puis le
guider, sur lun des chemins choisis comme privilgis, vers la destination (la borne) ; des
observations faites sur le site considr permettront de spcifier ces PPs : des PPs faciles, si
possible peu encombrs et prsentant moins de dtours, dobstacles et de risques de collisions
devront tre choisis ; On pourrait par ailleurs identifier ces chemins privilgis par une
observation, effectue sur un nombre suffisant de PAM, des meilleures stratgies de
cheminements adopts par eux sur le site. Pour cette application, le client agent sera install sur
le PDA ou smartphone du PAM et la carte radio du site construite par calibrage et charge dans
les bornes prsentes sur le site. Aprs lassociation de son PDA avec une borne, la PAM peut
recevoir un message auditif par le biais de son PDA lui demandant sil veut profiter du service
de guidage (car il se peut que la station de bus soit juste ct de lui et quil puisse la localiser
daprs sa sonnerie sans avoir besoin du service de guidage). Si la PAM accepte le service, le
logiciel de positionnement dtecte le PDA et le localise. Ce logiciel choisit le PP le plus proche
de la position du PAM et essaye de le guider sur ce PP en utilisant des consignes de guidage
bien dtermines (tu es droite du PP, sa gauche, tourne droiteetc ). On appellera ces
messages Messages de Position. Le logiciel pourra envoyer des messages de position avec
une priode rapproche tant que la PAM est en dehors du chemin privilgi. Quand la PAM est
positionne sur le chemin choisi, le logiciel de positionnement lui envoie un message de position
du genre Tu es sur le bon chemin!! avec une frquence de rptition plus faible ou
ventuellement sur dclenchement par la PAM (appui sur une touche pour demande de
confirmation). Si la PAM sloigne du PP, les messages de position frquents seront nouveau
gnrs. Arrivant proximit de la borne, un message de Bien arriv peut se faire entendre.
On illustre ceci par le schma de la figure 56 ci-dessous.

Universit Paris-Est
Figure 56- Intgration de RWPS
Une autre application utile pour RAMPE/INFOMOVILLE est celle qui consiste indiquer une
autre personne la position du PAM de faon permettre cette personne daller la rencontre
du PAM. On peut imaginer un service individualis dassistance dans les gares par exemple.
Pour cette application, la personne assistante dispose elle aussi dun PDA ou smartphone sur
lequel elle reoit une carte du lieu avec la position du PAM.
Diffrents points seront considrer dans limplmentation dun tel systme de positionnement.
On peut citer les points suivants :
- Implantation dans un site complexe de grandes dimensions : lexprimentation faite pour

montrer la fiabilit de la solution propose (la solution RWPS) a eu lieu dans un site en
espace ouvert et lintrieur dune mme zone, tandis que, lun des objectifs de
lintgration dun tel systme de guidage dans RAMPE/INFOMOVILLE est de proposer
une extension de cette application a utilisable dans les btiments de transport public et les
ples dchanges et donc dans de grands sites composs parfois de plusieurs tages ou
zones. Dans ce cas, les diffrentes zones doivent tre calibres et leurs cartes radios
sauvegardes dans la base de donnes du serveur de positionnement ; les points daccs
des diffrentes zones et le serveur de positionnement doivent tre connects au mme
rseau, ce qui permettra au PDA agent, aprs son association un certain AP, de
transmettre les mesures des puissances des signaux reus au serveur de positionnement
qui calculera alors sa position sur le site; les escaliers, les couloirs et les frontires
sparant les diffrents tages ou zones peuvent de mme tre quips par des points
daccs et feront alors partie de la carte radio calibre.
- Prise en compte de lorientation des personnes pour le guidage : dans lexprimentation

de guidage du paragraphe 4.6, lorientation des personnes ntait pas fournie sparment,
elle ne pouvait tre dduite quindirectement en observant leur progression. Les personnes
guider ont t amenes dans un endroit du site calibr, aprs leur avoir band les yeux,

Universit Paris-Est
et ont t toujours orientes vers la destination (c..d dans la direction de la destination).

Le message Tourne dans le sens oppos nexistait pas dans le cadre de cette
exprimentation. Pour une utilisation de ce systme dans un environnement de transport
public complexe, la connaissance de lorientation de la personne devrait permettre
deffectuer un guidage plus efficace en particulier dans la phase avant le positionnement
sur un PP. Considrons le cas o la PAM est localise et doit tre guide vers la station de
bus. Le logiciel de positionnement la dtecte mais doit savoir quel message de guidage
utiliser: tu es sur le bon chemin, avance (si jamais la PAM est dtecte sur un PP) ou
bien tu es sur le bon PP mais la station de bus est derrire toi, et tu dois alors tourner
dans le sens oppos avant davancer. Lorientation du dispositif localiser influe sur les
puissances des signaux reus (les RSSI), aussi les systmes de positionnement comme
Ekahau recommandent-ils de prendre des chantillons dans toutes les directions possibles
lors du calibrage du site, pour une bonne prcision. Ce point na pas t considr dans le
cadre de cette thse et constitue alors un travail futur.
- Respect de la vie prive : des considrations de respect de la vie prive sont prendre en
compte. En effet, le logiciel de positionnement peut connatre ladresse MAC du dispositif
localiser.

Universit Paris-Est
Conclusions et perspectives
Actuellement, le dveloppement des rseaux sans fil 802.11, laugmentation continuelle de
leur dbit et de leur porte, lintgration dune interface approprie dans un grand panel de
terminaux (tlphones mobiles, PDA, portables,), et des nouveaux dispositifs intelligents
comme les PDA et les tlphones intelligents ainsi que les mthodes daccs aux donnes et aux
informations, rendent possible le dveloppement de nouvelles applications et systmes facilitant
la vie quotidienne par un accs simple des informations temps-rel. Dautre part, lintgration
et la promotion des personnes handicapes constituent lun des enjeux de nos socits. En ce qui
concerne lassistance aux personnes aveugles, des systmes lmentaires sappuyant sur des
tlcommandes ont t installs dans plusieurs villes. Mais les collectivits ont encore peu
dploy de services interactifs personnaliss exploitant les potentialits des technologies en
partie car de tels services, pour tre efficaces et fiables ncessitent la prise en compte de
contraintes ergonomiques fortes. Lutilisation de technologies gnriques conduisant des
services utiles tous et de faible cot devrait faciliter le dploiement de services plus ambitieux.
Dans cette thse, on sest intress aux personnes dficience visuelle, aveugles ou
malvoyantes (PAM) et aux diffrents systmes et outils dvelopps pour rpondre leurs
besoins et proccupations, notamment en ce qui concerne lutilisation des transports publics et
les dplacements dans les ples dchanges. Nous avons centr notre travail sur les transports
de surface car ils reprsentent une tche particulirement difficile pour une PAM.
Le travail sest appuy sur les acquis des projets RAMPE et INFOMOVILLE. Les
limitations de la version actuelle du systme RAMPE/INFOMOVILLE ont t analyses et des
amliorations ont t proposes pour les aspects protocoles rseau, localisation et guidage,
simulation de lapplication. Nous rsumons dans ce qui suit les principales contributions de cette
thse et nous introduisons quelques perspectives pour des travaux futurs.
Principales contributions
La thse a port sur deux aspects critiques de lapplication RAMPE/INFOMOVILLE : la
fiabilit de la transmission de donnes et la capacit localiser et guider lutilisateur de
manire robuste.
Les deux lments cls du systme RAMPE/INFOMOVILLE sont dune part la borne
embarque dans les points darrt de transport (composes dun point daccs et dun processeur
client/serveur dinformation) et dautre part lapplication intelligente embarque dans les
dispositifs (de type ordinateur de poche ou PDA, ou Smartphone) ports par l-utilisateur et
communiquant avec la borne travers un rseau WiFi. Ce rseau est soumis diffrentes
perturbations qui peuvent limiter la fiabilit de la transmission de donnes. Dans la version
actuelle de RAMPE/INFOMOVILLE, les messages urgents transmis depuis la borne vers les
PDAs, sont diffuss en utilisant le protocole UDP en mode broadcast. Ce protocole de la couche
transport du modle OSI, tant sans connexion, il manque de robustesse. Un protocole de
communication, principalement conu pour le transfert des messages urgents, a donc t
propos. Ce protocole, appel RAMPE/INFOMOVILLE Application Protocol (RAP) ajoute une
certaine fiabilit en introduisant une redondance au niveau des paquets envoys. Dautre part, il
permet de calculer le taux derreur paquets (PER) qui pourra tre utilis comme une mtrique

Universit Paris-Est
indicatrice de la qualit de la liaison radio WiFi et par suite utilis pour fabriquer un indicateur
de qualit de la transmission rseau. Cet indicateur peut tre traduit en un message
comprhensible par les utilisateurs du systme pour leur donner un degr de confiance en
lapplication et en leurs dispositifs. Ce protocole a t simul, valu et compar UDP sur
deux types de canaux : un canal rel pouvant tre perturb par plusieurs types dinterfrences, et
un canal modlis par un modle de Gilbert-Elliot en utilisant dans les deux cas le simulateur
OMNeT++. Afin de minimiser le temps de simulation, le modle de canal introduit simule les
erreurs au niveau paquet.
Dans la deuxime partie du travail, un service de localisation et de guidage est propos

pour tre intgr dans le systme RAMPE/INFOMOVILLE, qui, dans sa version actuelle, nen
possde pas lexception dun guidage sonore lapproche des bornes. On propose dutiliser la
technologie WiFi la fois pour la localisation et la communication. Le positionnement par ondes
radio WiFi est de plus en plus utilis. A la diffrence du GPS utilisant les systmes satellites, il
peut tre employ en indoor et en outdoor, ce qui permet une continuit de service. Nous avons
choisi dutiliser une approche de positionnement par la technique dempreinte radio qui permet
dobtenir une prcision suffisante pour ce type dapplication mais prsente comme inconvnient
principal le temps ncessaire pour calibrer un site avec la prcision voulue pour guider des
PAM. Dans cette thse, on a propos une solution qui renforce la prcision dans certains
endroits appels chemins prfrs et correspondant des parcours privilgis pour des PAM. On
ne cherche pas obtenir une trs bonne prcision uniforme sur lensemble dans le site, mais
uniquement sur les chemins privilgis ; la PAM sera localise sur le site puis guide travers
lun de ces chemins. Lefficacit de cette solution a t dmontre par une exprimentation faite
sur un site universitaire en zone ouverte.
Perspectives et travaux futurs

Les travaux raliss durant cette thse et les rsultats obtenus laissent la porte ouverte un
ensemble de perspectives pour des travaux futurs.
Validation du protocole RAP
Le protocole RAP propos dans cette thse a pour but dajouter une certaine fiabilit la
communication entre les bornes et les dispositifs des utilisateurs de lapplication
RAMPE/INFOMOVILLE spcifiquement la transmission en broadcast des messages urgents.
Lefficacit de ce protocole a t tudie par des exprimentations, o on a considr des
transmissions en mode unicast. Il serait intressant de vrifier que les conclusions restent valides
dans des transmissions en broadcast.
Dautre part, lutilisation des trames de bourrage et de statistique proposes pourra tre
dveloppe et analyse plus finement : la trame de bourrage sert synchroniser les diffrents
PDA avec le point darrt et leur permet de sonder le canal en estimant continument un taux
derreur paquet dans une fentre temporelle. Ce taux derreur paquet doit permettre de pouvoir
estimer au niveau de lapplication embarque les paramtres dun modle reprsentant ce canal,
dans ce travail nous avons considr un modle de Gilbert Elliot. Lenjeu est alors de dduire de
ces paramtres la classe du canal (bon, moyen ou mauvais) afin dadapter dun point de vue
ergonomique la manire et la forme selon lesquelles les informations sont fournies lutilisateur
du dispositif intelligent.
Les champs ouverts par ce travail sont :

Universit Paris-Est
La validation de la fiabilit du modle choisi, c'est--dire de sa gnricit pour toutes les

situations de transmission.
La mthodologie destimation des paramtres du modle en fonction des donnes
collectes, le taux derreur paquet.
Llaboration dune classification pertinente dun point de vue ergonomique des types de
canaux.
Lenjeu des trames dites statistiques dans ce travail est dinformer le point darrt des
conditions de rception des diffrents dispositifs utilisateurs. A partir de ces donnes le point
darrt pourra modifier son schma de transmission (nombre de rptition et intervalles entre ces
rptitions) sous la double contrainte de minimiser sa consommation et donc le nombre de
transmission et de maximiser la qualit de fonctionnement des dispositifs utilisateurs cest la
qualit du canal que chacun voit.
Proposition dune mthode de calibrage automatique
La localisation par ondes radio WiFi utilisant la mthode dempreinte radio dtaille dans
cette thse prsente un inconvnient qui est le temps mis pour calibrer un site. Pour une bonne
prcision de localisation, il est ncessaire de calibrer le site dune faon fine, en dautres termes
de prendre plusieurs points chantillons qui serviront comme points rfrences pour lestimation
de la position de lobjet mobile par le serveur de positionnement. Dans cette thse, une nouvelle
mthodologie de calibration a t propose, cherchant renforcer la prcision dans certains
endroits spcifiques du site plutt que dans le site entier. Ceci diminue le temps de calibrage tout
en obtenant une bonne prcision sur les zones de prfrence.
Cependant, la carte radio construite peut changer suite des vnements imprvus tels que la :
panne ou le dplacement de points daccs ce qui ncessitera lactualisation de la base de
donnes et le recalibrage du site. Une solution est la conception dune mthode de calibrage
automatique. Des tudes ont propos de telles solutions [51, 52, 127, 128], mais le calibrage
manuel reste pour le moment le plus adquat pour une bonne prcision de localisation [52]. Une
autre perspective est le dveloppement de techniques permettant de dtecter automatiquement
les changements de lenvironnement.
Une approche pourrait consister calibrer manuellement le site dans un premier temps, puis,
utiliser un systme de contrle surveillant la qualit de la localisation (le groupe ESIEE travaille
dj sur ce sujet) et gnrant une alerte de demande de recalibrage en cas de modification
importante constate. Un algorithme de mise jour automatique pourrait alors tre utilis qui
sappuierait sur le premier
Pour cet algorithme automatique, on peut imaginer par exemple, que lors de lenregistrement des
points chantillons durant la phase de calibrage, les distances aux diffrents points daccs soient
enregistres ; quand on dplace les points daccs vers une nouvelle position connue, les RSSI
des chantillons sauvegards seront modifies automatiquement en fonction de ces changements
(en fonction de la nouvelle distance sparant les points chantillons des points daccs). On peut
de mme imaginer un calcul automatique de cette distance de dplacement : par exemple les
points daccs peuvent tre localiss comme le sont les PDA et leurs coordonnes mises jour
suite un dplacement.

Universit Paris-Est
Utilisation dune mthode centralise dans le dploiement dun rseau WiFi
Dans le dploiement dun systme comme RAMPE/INFOMOVILLE, on pourra profiter

de la mthode rcente de dploiement dun rseau local sans fil, qui est la mthode centralise.
Cette mthode sappuie sur un contrleur central auquel seront connects les diffrents APs
(parmi les constructeurs de ces systmes, on peut citer Cisco, Aruba, 3Com, ). La
configuration des adresses IP, des SSIDs, est faite sur ce contrleur puis dploye vers les
diffrents APs ; de cette faon la configuration ne se fait plus sur chaque AP mais sur lensemble
des APs connects au contrleur. La configuration des canaux est automatique : le contrleur qui
connat la disposition des APs, pourra configurer automatiquement leurs canaux afin que les
canaux de deux APs voisins ninterfrent pas. Cette architecture centralise permettra aussi de
dtecter les APs en panne et la zone de couverture de chaque AP, .Une option intressante est la
possibilit quun AP augmente sa puissance dmission si lun de ses APs voisins est dtect
hors service afin dtendre sa couverture pour la zone que servait lAP en panne. Il pourrait aussi
tre utile de proposer, dans de tels systmes, un algorithme de calcul de la distance de
dplacement dun point daccs. Ces systmes peuvent tre intressants pour limplmentation
de RAMPE/INFOMOVILLE ainsi que pour les services de localisation et de guidage quon
cherche y intgrer.
Prise en compte de lorientation des personnes pour le guidage
Dans les exprimentations de guidage prsentes dans le chapitre 4 de ce manuscrit,

lorientation des personnes ntait pas fournie sparment, elle ne pouvait tre dduite
quindirectement en observant leur progression. Les personnes guider ont t amenes dans un
endroit du site calibr, aprs leur avoir band les yeux, et ont t toujours orientes vers la
destination (c..d. dans la direction de la destination). La personne guide supposait toujours ce
fait dans ses consignes de guidage. Le message Tourne dans le sens oppos nexistait pas
dans le cadre de cette exprimentation. Cependant, lorientation constitue un paramtre
important considrer pour une implmentation du systme propos sur un site rel en
particulier pour les consignes de guidage. Cette orientation peut tre obtenue par des capteurs
spcifiques ou indirectement en utilisant la carte radio, les mesures RSSI (influences par
lorientation de la personne) [43], le mouvement de la personne.
Autres perspectives pour la localisation :
Fusion des donnes GPS et WPS pour amliorer la localisation outdoor.

tude in situ de la continuit de localisation indoor-outdoor.
Test in situ dans des environnements fortement mtalliques (gares)
Autres perspectives pour les aspects communications :
Le rseau WiFi est de plus en plus dploy dans les environnements urbains ; de
nombreux points daccs peuvent tre dtects (une trentaine de points daccs actifs a t
constate durant des exprimentations faites sur site en 2007 [62]). Actuellement ceci ne
consitue pas un chanon vulnrable du systme RAMPE/INFOMOVILLE. Cependant, pour les
annes venir, le nombre des points daccs va srement continuer augmenter ainsi que le
traffic quils supportent et dune faon gnrale lutilisation de la bande radio ISM va voluer.
Cette augmentation de traffic pourra gnrer des interfrences. Il sera alors important voire
ncessaire de contrler lvolution de lutilisation de cette ressource afin de dterminer la

Universit Paris-Est
mthodologie de dploiement des applications utilisant les bandes de frquences ISM ou UNII
(Unlicensed National Information Infrastructure).
Extension diffrents types de transports et aux ples dchanges :
Le systme pourrait tre tendu pour un fonctionnement dans un environnement

multimodal incluant des transports de surface et des transports souterrains ainsi que des ples
dchanges, des centres commerciaux et diffrents btiments publics et ceci dans une
perspective de conception pour tous.

Universit Paris-Est
Bibliographie
BIBLIOGRAPHIE
[1] G. Baudoin, O. Venard, G.Uzan. The RAMPE Project: Interactive, Auditive

Information System for the Mobility of Blind People in Public Transports. Proc. of the
5th International Conference on Intelligent Transportation Systems Telecommunications,
ITST 2005. Brest France. June 2005.
[2] G. Baudoin, O. Venard, G. Uzan, A. Rousseau et al. How can blinds get information in
Public Transports using PDA? The RAMPE Auditive Man Machine Interface. Proc. of
the 8th European Conference for the Advancement of Assistive Technology in Europe,
AAATE 2005. Lille, France. September 2005.
[3] J. Sayah, G. Baudoin, O.Venard, B. El Hassan. Simulation using OMNeT++ of the

RAMPE system - an Interactive Auditive Machine helping blinds in Public Transport.
Proc. of the 3rd IEEE Region 8 International Conference on Computer as a Tool,
EUROCON 2005, Volume 2, p. 1028 - 1031. Serbia & Montenegro, Belgrade.
November 2005.
[4] Riginald G. Golledge, James R. Marston, C. Michael Costanzo. Attitudes of Visually

Impaired Persons Toward the Use of Public Transportation. University of California
Transportation Center. Berkeley, California. Journal of Visual Impairment & Blindness
Vo191, no 5, pp 446-459. September- October 1997.
[5] James R. Marston, Reginald G. Golledge. Quantitative and Qualitative Analysis of

Barriers to Travel by Persons with Visual Impairments and its Mitigation through
Accessible Signage. Proc. of the 10th International Conference on Mobility and
Transport for Elderly and Disabled Persons, TRANSED 2004. Hamamatsu, Japan. May
2004.
[6] William Crandall, Billie Louise Bentzen, Linda Myers, John Brabyn. New orientation
and accessibility option for persons with visual impairment: transportation applications
for remote infrared audible signage. Clinical and Experimental Optometry, volume 84,
number 3, p. 120-131. May 2001.
[7] Site du projet Blueyes : www.blueeyes.fr
[8] Final Report of the BIOVAM (Besoin en Information et en Orientation des Voyageurs
Aveugles et Malvoyants dans les transports collectifs) project phase 1 (April 1999) and
phase 2 (January 2003).
[9] J. Sayah, G. Baudoin, O.Venard, B. El Hassan. Architecture and Protocols of the

RAMPE system- An Interactive Auditive Machine Helping Blinds in Public Transport.
Proc. of the 2nd IEEE International Conference on Information & Communication
Technologies: from Theory to Applications, ICTTA06, Volume 1, p. 843 - 848.
Umayyad Palace, Damascus, Syria. April 2006.

Universit Paris-Est
Bibliographie
[10] Site de la socit EO-EDPS. Un chemin pour tous, une accessibilit commune.
http://www.eo-edps.fr. Lyon, France.
[11] Gilles CANDOTTI. Navworks, pour guider les mal voyants. Projet PREDIT, 2004.
Revue Recherche R&E Equipement dite par SG/Drast, N6, p 15, Mai 2006.
[12] J. Sayah, G. Baudoin, O.Venard, B. El Hassan. RAMPE/INFOMOVILLE Application

Protocol- Protocole Point Multipoint adapt au systme RAMPE/INFOMOVILLE-
Assistance aux Personnes Handicap Sensoriel pour leur Mobilit dans les Transports
Publics et en Ville. 5th International Conference on Sciences of Electronic,
Technologies of Information and Telecommunications, SETIT 2009. Hammamat,
Tunisia. March 2009.
[13] Sami Koskinen, Ari Virtanen. Navigation and Guidance System for the Blind. VTT
Industrial Systems, Finland, ITS World 2004.
http://virtual.vtt.fi/virtual/noppa/noppa%20eng_long.pdf
[14] RIAS Talking Signs- Baton Rouge. Disponible sur:

http://www.talkingsigns.com/SeattleSoundTransit.html
[15] Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
specifications, IEEE Standard 802.11, 1999.
[16] J. Sayah, G. Baudoin, O.Venard, B. El Hassan. Localization and Guidance in

RAMPE/INFOMOVILLE- an Interactive System of Assistance for Blind Travelers.
Proc. of the 2nd International Conference on the Applications of Digital Information and
Web Technologies, ICADIWT 2009. London Metropolitan University, UK. August 2009.
[17] Lan Wang, Zhisheng Niu, Yanfeng Zhu, Hui Deng, Masashi Yano. Integration of SNR,
Load and Time in Handoff Initiation for Wireless LAN. Proc. of the 14th IEEE
conference on Personal, Indoor and Mobile Radio Communications, PIMRC 2003,
volume 3, p. 2032 - 2036. Beijing, China. September 2003.
[18] Glenn Judd and Peter Steenkiste. Fixing 802.11 Access Point Selection. Carnegie
Mellon University- Graduate School of Industrial Administration. ACM SIGCOMM
Computer Communications Review. Volume 32, Number 3, July 2002.
Disponible sur: http://www.cs.cmu.edu/~glennj/scp/FixingAPSelection.html
[19] G. Baudoin, O. Venard, G. Uzan, A. Paumier, J. Cesbron. Le projet RAMPE: systme

interactif d'information auditive pour la mobilit des personnes aveugles dans les
transports publics. Proceedings of the 2nd French-speaking conference on Mobility and
Ubiquity computing, UbiMob 2005, vol 120, p. 169-176, ISBN: 1-59593-172-4.
Grenoble, France. Mai 2005.
[20] D. Maniezzo, M. Cesana, P. Bergamo, M. Gerla, K. Yao. Real-Time Caption Streaming

over WiFi Network. Proc. of the International Conference on Information Technology:
Research and Education, ITRE 2003, p. 316 - 320. Newark, New Jersey, USA. August
2003.

Universit Paris-Est
Bibliographie
[21] Andras Varga. OMNeT++- Discrete Event Simulation System. User Manual. March
2005. Disponible sur : www.omnetpp.org
[22] Ahmet Sekercioglu. Accurate Modelling of IPv4 and IPv6 Protocols with OMNeT++
Simulation Framework. Tutorials of the IEEE Region 10 International Conference on
Technology Enabling Tomorrow : Computers, Communications and Automation towards
the 21st Century, TENCON 2005. Melbourne, Australia. November 2005.
[23] Jean-Pierre Ebert, Andreas Willig. A Gilbert-Elliot Bit Error Model and the Efficient
Use in Packet Level Simulation. Telecommunication Networks Group, TKN Technical
Report TKN-99-002, Technical University Berlin, March 1999.
[24] Jangeun Jun, Pushkin Peddabachagari, Mihail Sichitiu. Theoretical Maximum

Throughput of IEEE 802.11 and its Applications. Proceedings of the Second IEEE
International Symposium on Network Computing and Applications, NCA 2003, p. 249,
ISBN: 0-7695-1938-5. Year 2003.
[25] H. Jinzeji, K. Hagishima. Real-time audio and video broadcasting of IEEE

GLOBECOM96 over the Internet using new software. IEEE Communications
Magazine. Volume 35, Issue 4, p. 34-38. April 1997.
[26] Sneha Kumar Kasera. Scalable Raliable Multicast in Wide Area Networks. Doctoral
Thesis. University of Massachusetts Amherst. ProQuest Dissertations & Theses,
Computer science, Electrical engineering. Order number AAI9950169, ISBN: 0-599-
53024-3, 152 pages, 1999.
[27] Mirko Antonini, Marina Ruggieri, Ramjee Prasad. Communications within the Galileo
Locally Assisted Services. Proceedings of IEEE Aerospace Conference 2004, Volume
2, p. 1312 - 1321. March 2004.
[28] Site de la socit Skyhook : http://www.skyhookwireless.com
[29] Yu-Chung Cheng, Yatin Chawathe, Anthony LaMarca, John Krumm. Accuracy
Characterization for Metropolitan-scale Wi-Fi Localization. Proc. of the 3rd
International Conference on Mobile systems, Applications, and Services, p. 233 245.
Seattle, Washington. 2005
[30] Jim Geier. Deploying Indoor WLAN Positioning Systems. Wi-Fi planet tutorials.
October 2002. Disponible sur: http://www.wi-fiplanet.com/tutorials/article.php/1487271
[31] Binghao Li, Andrew Dempster, Chris Rizos, Joel Barnes. Hybrid Method for
Localization Using WLAN School of Surveying and Spatial Information System.
Spatial Sciences Institute Biennial Conference, SSC 2005, Melbourne, Australia.
September 2005.
[32] Andrew Howard, Sajid Siddiqi, Gaurav S. Sukhatme. An Experimental Study of

Localization Using Wireless Ethernet. 4th International Conference on Field and
Service Robotics, FSR 2003. Lake Yamanaka, Japan. July 2003.

Universit Paris-Est
Bibliographie
[33] Jeffrey Hightower and Gaetano Borriello. A Survey and Taxonomy of Location
Systems for Ubiquitous Computing. University of Washington, Computer Science and
Engineering. Technical Report UW-CSE 01-08-03. August 24, 2001.
[34] Moustafa Youssef, Ashok Agrawala. The Horus WLAN Location Determination
System. Proc. of the 3rd International Conference on Mobile systems, Applications and
Services, MobiSys 2005, p. 205 218. Seattle, Washington. June 2005.
[35] Stefan Brning, Johannes Zapotoczky, Peter Ibach, Vladimir Stantchev. Cooperative
Positioning with MagicMap. Proc. of the 4th Workshop on Positioning, Navigation and
Communication, WPNC 2007, p. 17-22. March 2007.
[36] Matthew Rabinowitz, James J. Spilker. A New Positioning System Using Television
Synchronization Signals. IEEE Transactions on Broadcasting, Volume 51, Issue 1, p.
51 - 61. March 2005.
[37] Vijay Abhijit, Carla Ellis, Xiaobo Fan. Experiences with an Inbuilding Location
Tracking System: Uhuru. Proc. of the 14th IEEE conference on Personal, Indoor and
Mobile Radio Communications,PIMRC 2003, Volume 3, p.2789 2793. Beijing, China.
September 2003.
[38] Paramvir Bahl, Venkata N. Padmanabhan. RADAR: An In-Building RF-based User

Location and Tracking System. Proc. of the 19th Annual Joint Conference of the IEEE
Computer and Communications Societies, INFOCOM 2000, Volume 2, p. 775 - 784.
Tel Aviv, Israel. Mars 2000.
[39] Nissanka B. Priyantha, Anit Chakraborty, Hari Balakrishnan. The Cricket Location-
Support System. Proc. of the 6th ACM International Conference on Mobile Computing
and Networking, ACM MOBICOM, p. 32 43, ISBN 1-58113-197-6. Boston, MA,
August 2000.
[40] Teruaki Kitasuka, Kenji Hisazumi, Tsuneo Nakanishi. WiPS: Location and Motion
Sensing Technique of IEEE 802.11 Devices. Proc. of the 3rd International Conference
on Information Technology and Applications, ICITA, Volume 2, p. 346 - 349. Sydney,
July 2005.
[41] Christian Hoene, Andre Gunther, Adam Wlisz. Measuring the Impact of Slow User
Motion on Packet loss and Delay over 802.11b Wireless Links. Proc. of the 28th Annual
IEEE International Conference on Local Computer Networks, LCN 2003, p. 652- 662,
ISBN: 0-7695-2037-5. Bonn, Germany. October 2003.
[42] Pierpaolo Bergamo, Daniela Maniezzo, Kung Yao et al. IEEE 802.11 Wireless Network
Under Aggressive Mobility Scenarios. IEEE International Test Conference, ITC 2003.
Charlotte, NC, USA. September 2003.
[43] Site de la socit Ekahau. Ekahau Real Time Location System (RTLS).
www.ekahau.com

Universit Paris-Est
Bibliographie
[44] Angelos Vlavianos, Lap Kong Law, Ioannis Broustis et al. Assessing Link Quality in
IEEE 802.11 Wireless Networks: Which is the Right Metric?. 19th IEEE International
Symposium on Personal, Indoor and Mobile Radio Communications, PIMRC 2008.
Cannes, France. September 2008.
[45] Stefan Mangold, Sunghyun Choi, Peter May, Ole Klein et al. IEEE 802.11e Wireless
LAN for Quality of Service. IEEE International Performance Computing and
Communications Conference, IPCCC 2003. Phoenix, Arizona. April 2003.
[46] Anders Lindgren, Andreas Almquist, Olov Scheln. Evaluation of Quality of Service
Schemes for IEEE 802.11Wireless LANs. Proc. of the 26th Annual IEEE Conference on
Local Computer Networks, LCN 2001, p. 348 - 351. Tampa, Florida, USA. November
2001.
[47] Hua Zhu, Ming Li, Imrich Chlamtac, B. Prabhakaran. A Survey of Quality of Service in
IEEE 802.11 Neworks. Mobility And Resource Management. IEEE Wireless
Communications. August 2004.
[48] Maryvonne Dejeammes. Les systmes tlmatiques et laide au dplacement des

personnes aveugles et malvoyantes. Rapport pour le CERTU (Centre dtudes sur les
Rseaux, les Transports, lUrbanisme et les constructions publiques). Juin 2001.
[49] Jack Loomis, Reginald Golledge, Roberta Klatzky. Navigation System for the Blind:
Auditory Display Modes and Guidance. Presence, Vol. 7 (1998), pp. 193-203 by the
Massachusetts Institute of Technology. April 1998.
[50] Site de la socit Humanware, Qubec. Produit Trekker Breeze :

http://www.humanware.com/en-international/products/gps/trekker
[51] Florian Gschwandtner, Peter Ruppel. Automatic Calibration of Large-scale WiFi-

Positioning Systems. IEEE Global Telecommunications Conference, GLOBECOM
2008. New Orleans, USA. November 2008.
[52] Lus Felipe M. de Moraes, Bruno Astuto A. Nunes. CalibrationFree WLAN Location
System Based on Dynamic Mapping of Signal Strength. 4th ACM International
workshop on Mobility management and Wireless Access, MOBIWAC 2006. Spain.
October 2006.
[53] John Krumm, Eric Horvitz. LOCADIO: Inferring Motion and Location from Wi-Fi
Signal Strengths. First Annual International Conference on Mobile and Ubiquitous
Systems: Networking and Services, MOBIQUITOUS 2004, p. 4 - 13. Boston,
Massachusetts, USA. August 2004.
[54] Chiping Tang and Philip K. McKinley. Modeling Multicast Packet Losses in Wireless
LANs. 6th ACM international workshop on Modeling analysis and simulation of
wireless and mobile systems, MSWiM 2003. San Diego, USA. September 2003.
[55] Gerhard Halinger et Oliver Hohlfeld. The Gilbert-Elliott Model for Packet Loss in
Real Time Services on the Internet. 14th GI/ITG Conference on Measurement, Modeling

Universit Paris-Est
Bibliographie
and Evaluation of Computer and Communication Systems, MMB 2008. Germany. March
2008.
[56] Jean-Claude Sperandio, Grard Uzan, Nathalie Jobard. Difficults rencontres par les
aveugles et dficients visuels pour la consultation de sites WEB sur les transports et le
tourisme. Rapport dtude effectue dans le laboratoire dErgonomie Informatique de
luniversit Ren Descartes- Paris 5. Novembre 2002.
[57] Clmence Lhermey. Traitement des Messages Vocaux dAide aux Dplacements des
Personnes Dficientes Visuelles. Mmoire de Master en Humanit et Sciences
humaines- Mention Sciences Cognitives, Universit Lumire Lyon 2. Ralis sous la
direction de Claude Marin-Lamellet. Laboratoire LESCOT Bron, France. Juin 2006.
[58] Jrome Bertrand, Robert Allio. Linformation destine aux personnes mobilit rduite
dans les transports en commun. Institut dAmnagement et dUrbanisme de la Rgion
le-de-France. Dpartement Transports et Infrastructures. Fvrier 2005.
[59] J. R. Marston. Empirical measurements of barriers to public transit for the vision-
impaired and the use of remote infrared auditory signage for mitigation. 16th Annual
International Conference, Technology and Persons with Disabilities, CSUN 2001. Los
Angeles. March 2001.
[60] H. Ohkubo, M. Furukawa, K. Ito, S. Sasaki. Remote Infrared Audible Signage System
for Visually Impaired at Railway Station. 10th International Conference on Mobility and
Transport for Elderly and Disabled Persons, TRANSED 2004. Japon. May 2004.
[61] G. Baudoin, O. Venard, G. Uzan, A. Paumier, Projet RAMPE- Rapport final de la phase
1, mars 2005. Disponible .http://www.esiee.fr/~rampe/presentation.html
[62] G. Baudoin, O. Venard, G. Uzan, A. Paumier, Projet RAMPE- Rapport final de la phase
2, juin 2007. Disponible http://www.esiee.fr/~rampe/presentation.html.
[63] Yu-Xi Lim. Efficient Wireless Location Estimation Through Simultaneous Localization
and Mapping. Doctoral Thesis in Electrical and Computer Engineering- School of
Electrical and Computer Engineering. Georgia Institute of Technology. May 2009.
[64] Ladd, A.M., et al. Robotics-Based Location Sensing using Wireless Ethernet. 8th
International Conference on Mobile Computing and Networking, MobiCom 2002.
Atlanta Georgia- USA. September 2002.
[65] Paul Castro, Patrick Chiu, Ted Kremenek, RichardMuntz. A Probabilistic Room
Location Service for Wireless Networked Environments. Proc. of the 3rd International
Conference on Ubiquitous Computing, Ubicomp 2001, volume 2201 of Lecture Notes in
Computer Science, p. 18-34. Atlanta, Georgia, USA. September 2001.
[66] R. Farcy, R. Damaschini, R. Legras, R. Leroux et al. Perception de l'espace et

locomotion des non-voyants par profilomtrie laser : aides lectroniques la
locomotion. J3eA, Journal sur lenseignement des sciences et technologies de
linformation et des systmes, Volume 3, Hors-Srie 1, 5. 2004.

Universit Paris-Est
Bibliographie
[67] Christophe Jacquet, Yacine Bellik, Ren Farcy, Yolaine Bourda. Aides lectroniques
pour le dplacement des personnes non-voyantes: vue d'ensemble et perspectives. 16me
Confrence Francophone sur lInteraction Homme-Machine, IHM 2004. Belgium. Aot
2004.
[68] Michel Banatre, Paul Couderc, Julien Pauty, Mathieu Becus. Ubibus: Ubiquitous
computing to help blind people in public transport. Proc. of the International
Symposium on Mobile Human-Computer Interaction, MobileHCI 2004,
vol. 3160, p. 310-314. Glasgow, Scotland. September 2004.
[69] Julian Hine, Derek Swan, Judith Scott, David Binnie, John Sharp. Using Technology to
Overcome the Tyranny of Space: Information Provision and Wayfinding. Urban Studies
Journal, UK, Vol. 37, No. 10, p. 1757-1770, 2000.
[70] Gill Whitney. The Use of Remotely Triggered Talking Sign Systems by Blind and
Partially Sighted People. Joint Mobility Unit- Royal National Institute for the Blind.
London, W1N 6AA. August 1998.
[71] L. R. Rabiner. A Tutorial on Hidden Markov Models and Selected Applications in

Speech Recognition. Proceedings of the IEEE, Vol.77, No.2, p.257-286, 1989.
[72] Ugo Biader Ceipidor, Carlo Maria Medaglia. Sesamonet: Mobile Navigation Services
for Visually Impaired. Smart Mobility- Building Trusted Mobile Applications. Sophia-
Antipolis, French Riviera. September 2008.
[73] Site de la socit ESIUM - Concepteur de solutions pour informer, orienter, guider:
Modules Sonores pour feux pitons- Informer les Personnes Dficientes Visuelles en
Milieu Urbain. http://www.esium.fr/esium/fr/Sinfea.html
[74] Adam Lipka , Rafal Niski. The Concept of the GALILEO Receiver. Proc. of the 4th
IEEE Region 8 International Conference on Computer as a Tool, EUROCON 2007, p.
1106 - 1112. Warsaw, Poland. September 2007.
[75] Galilo, un systme de navigation par satellites pour lEurope. CNES magazine, Juillet
1999, ISSN 1283-9817.
[76] Hitachi Ltd. Launch of Hitachi AirLocation(TM), a Wireless LAN-Based Location

Detection System Achieving Highly Accurate Positioning with Small Error Range of 1
to 3 Meters. http://www.hitachi-cable.co.jp/en/infosystem/news/20031119la.html
[77] Site de la socit Aeroscout. Wi-Fi RFID- AeroScout has partnered with all of the
leading WLAN equipment vendors to integrate industry-leading products in Enterprise
Networking and Wi-Fi RFID. Mars 2008. http://www.aeroscout.com/content/wi-fi-rfid
[78] David Garlan, Daniel P. Siewiorek, Asim Smailagic, Peter Steenkiste. Project Aura:
Toward Distraction-Free Pervasive Computing. Carnegie Mellon University. IEEE
Pervasive computing magazine, Volume 1, Issue 2, p. 22- 31, ISSN: 1536-1268. April
June 2002.

Universit Paris-Est
Bibliographie
[79] Johnny Shih. Wireless LAN Location System. School of Information Technology and
Electrical Engineering, The University of Queensland. Thesis submitted for the degree of
Master of Engineering- division of Telecommunications Engineering. November 2003.
[80] Ludmila Salaur. Building a Commodity Location-based Service at Botanic Garden of

University of Freiburg. Master thesis, Communication Systems Department, University
of Freiburg. 2005.
[81] Mathieu Bouet, Erwan Ermel, Guy Pujolle. Performances dune mthode de localisation
dans les rseaux sans fil mobiles. 8mes Journes Doctorales en Informatique et
Rseaux (JDIR), Marne la Valle, France. Janvier 2007.
[82] Site du service de localisation Ootay bas sur la golocalisation des tlphones portables.
http://www.ootay.fr/QuiSommesNous.asp
[83] Site de la socit 4TS Finland Oy. Produit 4TS dSeal :

http://www.4ts.com/dseal_r120.php
[84] Site de la socit APEX, Jesenice, Rpublique tchque. Page ddie au produit
TYFLOSET the electronic orientation and information system for the visually impaired
persons : http://www.apex-jesenice.cz/tyfloset.php?lang=en
[85] A. Shaik, N. S. Tlale, G. Bright. 2 DOF Resolution Adjustment Laser Position Sensor.
15th International Conference on Mechatronics and Machine Vision in Practice, MMVIP
2008, p. 233 - 238. Auckland, New Zealand. December 2008.
[86] George M. Giaglis, Ada Pateli, Kostas Fouskas et al. On the Potential Use of Mobile
Positioning Technologies in Indoor Environments. 15th Bled Electronic Commerce
Conference eReality: Constructing the eEconomy. Slovenia. June 2002.
[87] Pierluigi Caddeo, Ferdinando Fornara, Anna Maria Nenci, Amelia Piroddi. Wayfinding
tasks in visually impaired people: the role of tactile maps. 3rd International Conference
on Spatial Cognition, ICSC 2006. Rome, September 2006.
[88] David Guth, John Rieser. Perception and the control of locomotion by blind and
visually impaired pedestrians. In Blasch, B., Wiener, W., & Welsh, R. (Eds.).
Foundations of Orientation and Mobility, 9-39. 1997.
[89] Jack M. Loomis, Roberta L. Klatzky, Reginald G. Golledge. Navigating without Vision:
Basic and Applied Research. Optometry and Vision Science, vol. 78, no5, p. 282-289.
2001.
[90] Jack M. Loomis, Reginald G. Golledge, Roberta L. Klatzky, Jon M. Speigle, Jerome
Tietz. Personal guidance system for the visually impaired. First Annual ACM
Conference on Assistive Technologies, Assets 1994. California, USA. October l994.

Universit Paris-Est
Bibliographie
[91] Michael Wright, Dion Stallings, Derrek Dunn. The Effectiveness of Global Positioning
System Electronic Navigation. Proc. of the IEEE SoutheastCon 2003, p. 62 67, ISBN
0-7803-7856-3/03. Ocho Rios, Jamaica. April 2003.
[92] Projet ANR-PREDIT. DANAM Dispositif dAssistance la Navigation pour personnes

Aveugles dans les couloirs du Mtro. Partenaires CEA, RATP, PGES, THIM P-8.
[93] Maryvonne Dejeammes, Grard Uzan, MBalo Seck, Catherine Sidot. Dplacements
des dficients visuels en milieu urbain. Analyse des besoins en scurit, localisation et
orientation, et pistes d'volution. Recherche pour le Centre dtudes sur les Rseaux,
les Transports, lUrbanisme et les constructions publiques (CERTU). Lyon, France.
Novembre 2008.
[94] Bertrand Theys. Faciliter laccs aux transports des personnes mobilit rduite.
Secrtariat permanent du PREDIT, Carrefour final, Mai 2008.
[95] Site de la socit Phitech- Alle Pelletier Doisy - 54603 Villers-ls-Nancy Cedex.
Actitam, une rponse performante, simple mettre en uvre pour rpondre
tous les besoins d'information des dficients visuels.
http://www.phitech.fr/solution.html
[96] Uzan G., Seck M., Dejeammes M., Rennesson C. Besoins en scurit, localisation et
orientation des dficients visuels en milieu urbain: analyse de la situation et pistes
dvolution. http://cnpsaa.fr/ accessibilit de la Commission Accessibilit du CNPSAA.
Anne 2008.
[97] Site de la socit ANGEO Technology : http://www.angeo.fr/
[98] B. N. Walker, J. Lindsay. Navigation performance with a virtual auditory display:

Effects of beacon sound, capture radius, and practice. Human Factors,
vol. 48, no2, p. 265-278. 2006.
[99] J H Snchez and C A Oyarzn. Mobile audio assistance in bus transportation for the
blind. 7th International Conference on Disability, Virtual Reality and Associated
Technologies with ArtAbilitation, ICDVRAT 2008. Maia & Porto, Portugal. September
2008.
[100] Socit VisuAide, Montral, Canada. VisuAide's Trekker GPS system creates handheld
personal guide with HP iPAQ Pocket PC. Communiqu de presse, 2003.
[101] Hewlett-Packard. HP and VisuAide Launch Maestro - First Handheld PC for the
Blind. National Federation of The Blind Conference. Atlanta. June 2004.
[102] Association pour le Bien des Aveugles et malvoyants (ABA). ABA plans- Plans de ville
pour personnes aveugles. 7me Congrs de lUnion Mondiale des Aveugles. Geneva.
Aot 2008.
[103] Franois Rambaud, Maryvonne Dejeammes. Pour des systmes de transports collectifs
et dinformation accessibles tous. 11th International Conference on Mobility and

Universit Paris-Est
Bibliographie
Transport for Elderly and Disabled Persons, TRANSED 2007. Montral, Canada. June
2007.
[104] Jack M. Loomis, James R. Marston, Reginald G. Golledge, Roberta L. Klatzky.

Personal Guidance System for People with Visual Impairment: A Comparison of
Spatial Displays for Route Guidance. Journal of Visual Impairment and Blindness,
April 2005.
[105] Alireza Darvishy, Hans-Peter Hutter, Peter Frh et al. Personal Mobile Assistant for Air
Passengers with Disabilities (PMA). 11th International Conference Computers Helping
People with Special Needs, ICCHP 2008. Linz, Austria. July 2008.
[106] G. Baudoin, G. Uzan, O. Venard. Prsentation des rsultats dexprimentation du projet

RAMPE. CERTU, groupe dchanges AOTU-exploitants sur laccessibilit des
rseaux de transports urbains de surface. Lyon, France. Dcembre 2007.
[107] Site du RNIB prsentant le systmes RNIB REACT :

http://www.rnib.org.uk/professionals/accessibleenvironments/signagewayfinding/rnibrea
ct/Pages/rnib_react.aspx
[108] Brighton & Hove City Council - Talking Bus Stops for the blind and visually impaired
(linked to Real Time Bus Information signs). Case study, Public Technology, UK. April
2008.
[109] Kooijman A.C, Uyar M.T. Walking speed of visually impaired people with two talking
electronic travel systems. Visual Impairment Research, Volume 2, Number 2, p.81-
93(13).August 2000.
[110] Marie-France Dessaigne, Flore Lequatre. Accessibilit de linformation aux usagers

dficients sensoriels dans les transports collectifs urbains. Etude effectue par le cabinet
Ergonomos pour le CERTU. Avril 2005.
[111] Reginald G. Golledge, James R. Marston. Towards an Accessible City: Removing

Functional Barriers to Independent Travel for Blind and Vision Impaired Residents and
Visitors. Part of the California PATH Program of the University of California.
September 1999.
[112] James R Marston, Reginald G. Golledge. Removing Functional Barriers: Public Transit
and the Blind and Vision Impaired. Transportation Center of the University of
California at Berkeley. Proceedings of the Society for Disability Studies. 1997.
[113] M.-F. Dessaigne. Infomoville, un dispositif qui rend la ville plus accessible aux mal
voyants. Colloque GERRA 2008.
[114] A. LaMarca, Y. Chawathe, S. Consolvo, J. Hightower, G. Borriello et al. Place Lab:

Device positioning using radio beacons in the wild. 3rd International Conference on
Pervasive Computing. Munich, Germany. May 2005.
[115] Cisco Systems. Serveur de localisation sans fil Cisco. www.cisco.com

Universit Paris-Est
Bibliographie
[116] Cratty, B. J. The perception of gradient and the veering tendency while walking without
vision. American Foundation for the Blind, Research Bulletin, 14, 13-51, in Hatwell Y.
2003.
[117] M.-F. Dessaigne, G. Baudoin, G. Uzan, O. Venard. Accder linformation Voyageurs

quand on a un handicap sensoriel visuel ou auditif. Et lergonomie et le Design dans ce
systme innovant ?. Colloque Ergo Design, Lyon, France. Juin 2009.
[118] Klatzky, R.L. Loomis, J.M. Golledge, R.G. Cicinelly et al. Acquisition of route and
survey knowledge in absence of vision. Journal of Motor Behaviour, University of
California, Santa Barbara, 22, 1, (1990),19-43.
[119] G. Uzan. Technologies pour le dplacement des dficients visuels en milieu urbain et
dans les transports. Prsentation lInstitut Fdratif de Recherche sur les Aides
Techniques pour personnes Handicapes, IFRATH. Mai 2009.
[120] David Harris, Gill Whitney. Visually Impaired people and Public Transport
Information. Proceedings of the IEEE Colloquium on Public Transport Information and
Management Systems, p. 5/1 - 5/7. London, UK. May 1993.
[121] The MoBIC project. University of Magdeburg, Germany. Project being supported by
the Commission of the European Union through the TIDE program (Technology
Initiative for Disabled and Elderly people). April 1996. http://isgwww.cs.uni-
magdeburg.de/projects/mobic/mobicuk.html
[122] H. Makino, I. Ishii, M. Nakashizuka. Development of navigation system for the blind
using GPS and mobile phone connection. 18th annual meeting of the IEEE Engineering
in Medicine and Biology Society, EMBS 1996. Amsterdam, Netherlands. October 1996.
[123] D. Guth, R. Laduke. The veering tendency of blind pedestrians: an analysis of the
problem and literature review. Journal of Visual Impairement and Blindness, 88, 1994,
91-400.
[124] G. Baudoin, O. Venard, M.-F. Dessaigne, G. Uzan, Y. Lemaitre. Rapport davancement

du projet INFOMOVILLE. Juin 2008.
[125] Site de ZigBee Alliance. ZigBee Architecture Overview. Embedded Systems

Conference Silicon Valley April 2006. http://www.zigbee.org/
[126] Patrick Kinney. ZigBee Technology: Wireless Control that Simply Works.
Communications Design Conference. San Jose, California. October 2003.
[127] Youngjune Gwon, Ravi Jain. Error Characteristics and Calibration-free Techniques for
Wireless LAN-based Location Estimation. 2nd International workshop on Mobility
management and Wireless access protocols, MobiWac 2004. Philadelphia, Pennsylvania,
USA. September 2004.

Universit Paris-Est
Bibliographie
[128] Xiaoyong Chai Qiang Yang. Reducing the Calibration Effort for Location Estimation
Using Unlabeled Samples. 3rd IEEE International Conference on Pervasive Computing
and Communications, PerCom 2005, p. 95 - 104 . Kauai Island, HI. March 2005.
[129] Jaime Lopez Krahe. Introduction to Assistive Technology for the Blind. Information
technologies for visually impaired people, Cepis Upgrade, the European Journal for the
Informatics Professional, Vol. 8, issue no. 2. April 2007.
http://www.upgrade-cepis.org/issues/2007/2
[130] D. Moreno Eddowes, J. Lopez Krahe. Pedestrian Traffic Lights Recognition in a Scene
using a PDA. Visualization, Imaging, and Image Processing (VIIP 2004). Marbella,
Spain. September 2004.
[131] Yang Xiao. Throughput and Delay Limits of IEEE 802.11. IEEE Communications
letters Volume 6, Issue 8, p. 355- 357, ISSN: 1089-7798. August 2002.
[132] M. Mokhtari, M.A Feki. User needs and usage analysis in a smart environment for
people requiring assistance. Topics in Geriatric Rehabilitation, Volume 23, Number 1,
p.52-59. January-March 2007.
[133] Mohamed Ali Feki, Sang Wan Lee, Z. Zenn Bien, Mounir Mokhtari. Combined Fuzzy
State Q-learning Algorithm to Predict Context Aware User Activity under Uncertainty in
Assistive Environment. Proc. of the 9th ACIS International Conference on Software
Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing,
SNPD 2008, p. 57 - 62. Phuket, Thailand. August 2008.
[134] M. Mokhtari, M. Ghorbel, M.A. Feki. From Smart home to smart space in independent
living: a framework for multiple contexts management. 3rd IEEE international
Conference on Wireless and Mobile Computing Networking and Communications,
WIMOB'2007. New-York City, USA. October 2007.
[135] Daqing Zang, M. Mokhtari. Toward a human-friendly assistive environment (Assistive

Technology Research series), 300 pages, Proceedings of the 2nd International
Conference On Smart homes and health Telematics, ICOST'2004. Singapore. September
2004.
[136] Johnson, J., Johnson, B., Blasch, B., De l'Aune, W. Gait and long cane kinematics: A
comparison of sighted and visually impaired subjects. Journal of Orthopedic & Sports
Physical Therapy, Volume 27, no2, p. 162-166, 2008.
[137] Bruce B. Blasch, William R. Wiener, Richard L. Welsh. Foundations of Orientation and
Mobility, Second edition, Length: 800 pp, ISBN: 978-0-89128-946-3, Publisher: AFB
Press, 1997.
[138] Tetsuo Kamina, Noboru Koshizuka, Ken Sakamura. Embedding Legacy Keyword
Search into Queries for the Ubiquitous ID Database. 2nd International Conference on
Network-Based Information Systems, NBiS 2008. Turin, Italy. September 2008.

Universit Paris-Est
Bibliographie
[139] K. Sakamura. Ubiquitous computing: Making it a reality. In ITU TELECOM World p.
1-9, 2003.
[140] Sakamura, K. Ucode Architecture and RFID. In 2004 RFID International Symposium,
pp. 3-24, T-Engine Forum. Ubiquitous ID Center: http://www.uidcenter.org
[141] Lisa Ran, Sumi Helal, Steve Moore. Drishti: An Integrated Indoor/Outdoor Blind
Navigation System and Service. Proceedings of the 2nd IEEE International Conference
on Pervasive Computing and Communications, PerCom 2004, p.23. Orlando, Florida,
USA. March 2004.
[142] David Harris, Gill Whitney. Visually Impaired people and Public Transport
Information. Proceedings of the 6th International Conference on Mobility and
Transport for elderly and Disabled Persons. Lyons. May 1992.
[143] Walker, B. N., Lindsay, J. Using virtual reality to prototype auditory navigation
displays. Assistive Technology Journal 17(1), p. 72-81, 2005.
[144] O. Venard, G. Baudoin, G. Uzan. Field Experimentation of the RAMPE Interactive

Auditive Information System for the Mobility of Blind People in Public Transport: Final
Evaluation. 9th IEEE International Conference on ITS Telecommunications, ITST 2009.
Lille, France. Octobre 2009.
[145] O. Venard, G. Baudoin, G. Uzan. Experiment and evaluation of the RAMPE interactive
auditive information system for the mobility of blind people in public transport. 10th
ACM Conference on Computers and Accessibility, ASSETS 2008. ISBN: 1-59593-976-0.
ACM, pp. 271-272. Halifax, Nova Scotia. Canada. Octobre 2008.
[146] A. Smailagic, D. Kogan. Location Sensing and Privacy in a Context-Aware Computing

Environment. IEEE Wireless Communications, Volume 9, Issue 5, p. 10- 17, ISSN:
1536-1284. October 2002.
[147] C. Chen, M. Asawa, B. Foreman. Outdoor Measurements on WaveLAN Radio.

Technical Report, California Path Program, technical note 96-2. April 1996.
[148] Site de la socit Freedom Scientific, St. Petersburg, produit StreetTalk:

http://www.freedomscientific.com/products/fs/streettalk-gps-product-page.asp
[149] R. Ivanov. Mobile GPS navigation application, adapted to visually impaired people.
Proccedings of the International Association for the Scientific Knowledge conference
(IASK 2009), Session W 1.5 - E-Health, ICT and People with Disabilities. Spain. June
2009.
[150] Kamol Kaemarungsi, Prashant Krishnamurthy. Modeling of Indoor Positioning Systems

Based on Location Fingerprinting. Proceedings of the 23rd AnnualJoint Conference of
the IEEE Computer and Communications Societies, INFOCOM 2004,
Volume: 2, p. 1012- 1022, ISBN: 0-7803-8355-9. Hong Kong. March 2004.

Universit Paris-Est
Bibliographie
[151] Julia Letchner, Dieter Fox, Anthony LaMarca. Large-Scale Localization fromWireless
Signal Strength. Proc. of the 20th National Conference on Artificial Intelligence (AAAI
2005), Volume 1, p. 15-20, ISBN: 1-57735-236-x. Pittsburgh, Pennsylvania. July 2005.
[152] Dieter Fox, Jeffrey Hightower, Gaetano Borriello et al. Bayesian Filters for Location
Estimation. IEEE pervasive computing, ISSN 1536-1268 , vol. 2, no3, pp. 24-33 [10
page(s)], 2003. Published by the IEEE Computer Society, 2002.
[153] B. Tth, G. Nmeth. Speech Enabled GPS Based Navigation System in Hungarian for
Blind People on Symbian Based Mobile Devices. Regional Conference on Embedded
and Ambient Systems, RCEAS 2007. Budapest, Hungary. November 2007.
[154] Christopher Drane, Malcolm Macnaughtan, Craig Scott. Positioning GSM Telephones.
IEEE Communications Magazine, Volume: 36, Issue 4, p. 46-54, 59. ISSN: 0163-6804.
April 1998.
[155] Teemu Roos, Petri Myllymki, Henry Tirri et al. A Probabilistic Approach to WLAN
User Location Estimation. International Journal of Wireless Information Networks, Vol.
9, No. 3, July 2002.
[156] Pelletta, E.; Velayos, H. Performance measurements of the saturation throughput in

IEEE 802.11 access points. Proc. of the 3rd International Symposium on Modeling and
Optimization in Mobile, Ad Hoc, and Wireless Networks, WIOPT 2005. Volume 3, Issue
7 p. 129 138. Italy, April 2005.
[157] Roy Want, Veronica Falcao, Jon Gibbons. The Active Badge Location System. ACM
Transactions on Information Systems. Volume 10, p. 91-102. 1992.
[158] Atul M Gonsai. Bandwidth Performance testing of IEEE 802.11Wireless Local Area
Networks. Proceedings of the International MultiConference of Engineers and
Computer Scientists, IMECS 2009, Vol I. Hong Kong. March 2009.
[159] P. Foucher, D. Moreno Eddowes, J. Lopez Krahe. Traffic light silhouettes recognition
using Fourier descriptors. Proc. of the 5th International Conference Visualisation
Imaging and Image Processing, VIIP 2005. pp 186-190. Benidorm, Spain. September
2005.
[160] M. Ghorbel, R. Kadouche, M. Mokhtari. User & service modeling in assistive

environment to enhance accessibility of dependent people. 1st International Conference
on ICT & Accessibility, ICTA 2007. Hammamet, Tunisia. April 2007.
[161] M. Mokhtari. Human-centric Approach in Designing Assistive Living Environments.

8th International Workshop on Human-Friendly Welfare Robotic Systems, HWRS'2007.
Daejon, Korea. October 2007.
[162] Okadome Takeshi, Yamazaki Tatsuya, Mokhtari Mounir. Pervasive Computing for
Quality of Life Enhancement. 5th International Conference on Smart Homes and
Health Telematics, ICOST 2007. Nara, Japan. June

Universit Paris-Est
Bibliographie
[163] C. Penaud, M. Mokhtari, B. Abdulrazak. Technology Usage for dependant people:
Towards the right balance between user needs and technology. Proc. of the 9th
International Conference on Computers Helping People with Special Needs, ICCHP
2004 pp. 898-905. Paris, France. July 2004.
[164] Martin Heusse, Franck Rousseau, Gilles Berger-Sabbatel, Andrzej Duda. Performance
Anomaly of 802.11b. Proc. of the 2nd Annual Joint Conference of the IEEE Computer
and Communications, INFOCOM 2003, Volume 2, p. 836- 843, ISBN: 0-7803-7752-4.
San Francisco, California, USA. April 2003.
[165] M. H. Manshaei, G. R. Cantieni, C. Barakat, T. Turletti. Performance Analysis of the

IEEE 802.11 MAC and Physical Layer Protocol. Proc. of the 6th IEEE International
Symposium on a World of Wireless Mobile and Multimedia Networks, WoWMoM'05.
ISBN: 0-7695-2342-0. Taormina, Italy. June 2005.
[166] Kartikeya Tripathi, Janise McNair, Haniph Latchman. Directional Antenna Based
Performance Evaluation of 802.11 Wireless Local Area Networks. From the book
Intelligence in Communication Systems, IFIP International Federation for Information
Processing series, Volume 190/2005, p.211-220, ISBN: 978-0-387-29121-5.
[167] Wireless LAN medium access control (MAC) and physical layer (PHY) specification:
High-speed physical layer extension in the 2.4 GHz band, IEEE Standard 802.11, 1999.
[168] Wireless LAN medium access control (MAC) and physical layer (PHY) specification:
High-speed physical layer in the 5 GHz band, IEEE Standard 802.11, 1999.
[169] Site de loutil Iperf. National Laboratory for Applied Network Research :
http://iperf.sourceforge.net/
http://dast.nlanr.net/Projects/Iperf/
[170] Site du logiciel Wireshark : http://www.wireshark.org/
[171] Site du logiciel Matlab : http://www.mathworks.fr/
[172] MichaelWallbaum, Stefan Diepolder. Benchmarking Wireless LAN Location Systems.

Proc. of the 2nd IEEE International Workshop on Mobile Commerce and Services,
WMCS05. p. 42-51, ISBN: 0-7695-2391-9. Munich, Germany. July 2005.
[173] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. RTP: A transport protocol for

real-time applications. IETF Audio-Video Transport Working Group, RFC 1889
(revised), 2001.
[174] Matthieu Petit, Henning Christiansen. Un calcul de Viterbi pour un Modle de Markov
Cach Contraint. Publi dans Cinquimes Journes Francophones de Programmation
par Contraintes, Actes JFPC 2009. Orlans, France. Juin 2009.

Universit Paris-Est
Annexe A
Annexe A
Ekahau Real time Location System (RTLS)
1- Carte du site utilise pour les exprimentations avec Ekahau
Pour assurer un bon fonctionnement du logiciel EPE, on doit dfinir lchelle exacte de la carte.
On disposait dune carte au format Autocad et grce l'chelle inscrite sur cette carte, on a pu
dterminer la distance exacte entre deux points et en dduire le rapport pixels/mtres.
Cette information est entre dans le logicel Ekahau.
La figure 57 montre le plan du site utilis pour les exprimentations et illustre lopration
effectuer pour fournir lchelle exacte de la carte.
Figure 57- Insrer lchelle exacte de la carte du site
2 - Visulation des puissances des signaux reus des diffrents points daccs
Le logiciel Ekahau Manager permet de visualiser le niveau de puissance des signaux des
diffrents APs (cf. figure 58).

Universit Paris-Est
Annexe A
Figure 58- Puissance des signaux des APs visualiss sur Ekahau Manager
3 - Choix des Points dAccs contribuant la localisation
Les points d'accs dtects n'appartiennent pas ncessairement notre rseau. Ceci peut
fausser les rsultats si la position de ces APs est modifie sans quon le sache. Pour viter ces
problmes, on peut choisir de ne pas utiliser les points d'accs qui ne nous appartiennent pas.
On peut slectionner les points daccs quon veut utiliser dans la localisation dans "Access
Point View".
4- Dessin des rails de cheminement

Les rails de cheminement doivent tre placs sur la carte pour indiquer les chemins possibles
entre les salles, les couloirs en indoor par exemple.
- On active l'outil de rail en cliquant son icne (cf. figure 59).

- On place l'indicateur de souris au centre d'un chemin, d'une salle, ou d'un couloir de
marche, et on clique la carte une fois pour crer un point de dpart.
- On dplace l'indicateur sur le chemin sans croiser de murs ni dobstacles. On clique sur la
carte une deuxime fois pour crer un nouveau point du rail et on continue ainsi jusqu la
fin du trac du rail souhait.

Universit Paris-Est
Annexe A
Figure 59- Les rails de cheminement
La partie indique par une flche sur la figure 59 reprsente le plan du site de lexprimentation
effectue dans le chapitre 4 de ce mmoire (cf. figure 60) :
Figure 60- Plan du site de lexprimentation

Universit Paris-Est
Annexe A
5 - Calibrage du site
- Sur lordianteur portable o le logiciel Ekahau Manager est install, on active l'outil de
calibrage.
- On dplace l'indicateur de souris lendroit o on se situe et on clique la carte pour
enregistrer un PR (point de rfrence ou chantillon).
- En restant au mme endroit, on peut tourner dans toutes les directions pour enregistrer des
PR.
- On rpte l'tape (cf. figure 61)
Figure 61- Enregistrement des PR
Il est recommand:
- d'enregistrer un PR tous les 3-5 mtres
- d'enregistrer un PR sur toutes les intersections des rails
- d'enregistrer un PR sur toutes les extrmits des rails
- denregistrer un PR dans tous les endroits o l'environnement radio change soudainement.
Par exemple, enregistrer un PR des deux cts d'une porte (typiquement d'une salle et d'un
couloir).

Universit Paris-Est
Annexe A
Figure 62- Carte du site calibre
Les rectangles verts sur la figure 62 reprsentent la couleur indicatrice des RSSI reus par le
point chantillon enregistr.
A la fin du calibrage, on sauvegarde le modle.
6 - Positionnement
Aprs la phase de calibrage du site, on peut localiser des objets. Ces objets peuvent tre
des tiquettes Ekahau ou des objets disposant dune puissance de calcul (ordinateur, PDA,
smartphone) dans lesquels on a install le logiciel client. Dans cette thse on na travaill
quavec la deuxime approche (localisation de PC ou de PDA intgrant un logiciel client de
localisation).
Par exemple, pour localiser l'ordinateur portable o le logiciel Ekahau Manager est install, on
clique l'icne d'Ekahau sur le bandeau suprieur (cf. figure 63).
Figure 63- Positionnement des clients agents

Universit Paris-Est
Annexe A
Pour localiser n'importe quel autre dispositif, on slectionne Devices dans la partie infrieure
de lcran
On clique le checkbox "Tracking" pour chaque dispositif sur la liste pour le localiser.
Seuls les dispositifs o le client Ekahau est install apparatront sur la liste des dispositifs qui
peuvent tre localiss. Si on slectionne un client, en appuyant sur la touche droite de la souris,
on obtient un menu (cf. figure 64) avec les rubriques suivantes :
- Proprits : pour montrer les caractristiques du client telles que son adresse MAC
- Follow : pour maintenir automatiquement le client dans la carte de localisation
Figure 64- Spcifications du client localiser

Universit Paris-Est
Annexe B
Annexe B
Installation dOMNeT++
Initialement OMNeT++ a t dvelopp sur Linux mais actuellement il fonctionne sur la
plupart des systmes Unix et plateformes Windows (NT4.0, Windows 2000 ou Windows XP) :
Win32 et Cygwin32 ou encore Win32 et Microsoft Visual C++.
Installation des outils gratuits de compilation C++ Microsoft
On dcrit les tapes ncessaires pour l'installation des outils gratuits de compilation C++
(VC7) ncessaire pour travailler avec l'environnement de simulation OMNeT++:
1- Tlcharger l'environnement de compilation Microsoft Visual C++ Toolkit 2003 puis:
Crer la variable d'environnement "VCToolkitInstallDir" avec comme valeur le

rpertoire d'installation, par exemple "C:\Program Files\Microsoft Visual C++ Toolkit
2003".
Mettre jour la variable d'environnement"PATH" en rajoutant
"%VCToolkitInstallDir%bin;"
Mettre jour ou crer la variable d'environnement "INCLUDE" avec la valeur
"%VCToolkitInstallDir%include;%INCLUDE%."
Mettre jour ou crer la variable d'environnement "LIB" avec la valeur
"%VCToolkitInstallDir%lib;%LIB%."
2- OMNeT++ ncessite aussi d'autres librairies Microsoft, Microsoft Platform SDK. On les
tlcharge, on le sinstalle et on modifie les variables d'environnement suivantes
Crer la variable d'environnement "MSSdk" avec comme valeur le rpertoire

d'installation, par exemple "C:\Program Files\Microsoft Platform SDK"
Mettre jour la variable d'environnement "INCLUDE" avec la valeur
"%VCToolkitInstallDir%include;%MSSdk%Include;%INCLUDE%"
Mettre jour ou crer la variable d'environnement "LIB" avec la valeur
"%VCToolkitInstallDir%lib;%MSSdk%Lib;%LIB%".
Note : L'ordre des dclarations ci-dessus est important.
3- L'utilitaire Nmake n'est pas inclu dans la distribution Visual C++ Toolkit 2003, il est
donc ncessaire de Tlcharger et d'installer Microsoft .NET Runtime (Microsoft .NET
Framework Version 1.1 Redistributable Package) et de copier ensuite "nmake.exe" dans
le rpertoire "%VCToolkitInstallDir%bin".
Une fois ces outils C++ installs, le fichier excutable OMNeT++ (qui pourra tre tlcharg sur
le site dOMNeT++ www.omnetpp.org) peut tre lanc; il suffit de suivre les instructions
dinstallation.

Universit Paris-Est
Annexe B
4- La compilation du programme avec les librairies OMNeT++ et les outils Microsoft se
fait avec la squence de commandes suivantes:
- opp_nmakemake: permettant de crer un fichier Makefile
- nmake -f Makefile.vc: cration de l'excutable .exe

Universit Paris-Est
Annexe C
Annexe C
Codes de simulation
On intgre dans cette annexe les fichiers C++ et config (omnetpp.ini) dOMNeT++ de la
simulation dUDP et de RAP sur un canal rel et sur un canal modlis de Gilbert-Elliot.
****** Canal Rel ******
/* Client.cpp (idem pour la simulation sur un canal de Gilbert-Elliot) */
//
// Cest le code du client RAP dont la couche applicative envoie une trame urgente
//chaque t secondes la couche session. La couche session enverra une copie de la
//trame chaque tr secondes
//
#include <omnetpp.h>
#include "apppkt_m.h"
#include "rappacket_m.h"
class Application : public cSimpleModule

{
Module_Class_Members(Application,cSimpleModule,0);
private:
int addr, srvAddr, t;
protected:
virtual void initialize();
virtual void handleMessage(cMessage *msg);
void simulateUserTyping();
void processEcho(RAPPacket *rapPkt);
};
class Session : public cSimpleModule

{
Module_Class_Members(Session,cSimpleModule,0);
private:
int addr, srvAddr, type;
FILE *pFile;
protected:
int numServicesent,packet_limit;
double tr, freq;
int numSent;
char nuSent[5];
int i, nbrepetition, expected_repetitionnb;
cMessage *repetitiondata;
RAPPacket *data;
RAPPacket *Packet;
simtime_t expected_time;
// process packets from application

virtual void processMsgFromApp(APPPkt *msg);
virtual void sendRapPacket();

Universit Paris-Est
Annexe C
};
Define_Module(Application);
Define_Module(Session);
void Application::initialize()
{
addr = parentModule()->par("addr");
srvAddr = parentModule()->par("srvAddr");
cMessage *timer = new cMessage("timer");

scheduleAt(simTime()+parentModule()->par("sendIaTime").doubleValue(), timer);
}
void Session::initialize()
{
addr = parentModule()->par("addr");
srvAddr = parentModule()->par("srvAddr");
pFile=fopen("Client.txt","w");
numSent=i=0;
expected_repetitionnb=1;
freq=30;
tr=parentModule()->par("tr");
nbrepetition=par("nbrepetition");
expected_time=freq;
repetitiondata=new cMessage("sendTimer");
}
void Application::handleMessage(cMessage *msg)

{
if (msg->isSelfMessage())
{
simulateUserTyping();
scheduleAt(simTime()+parentModule()->par("sendIaTime").doubleValue(), msg);
}
else
{
processEcho(check_and_cast<RAPPacket *>(msg));
}
}
void Application::simulateUserTyping()
{
char msgpayload[1000];
sprintf(msgpayload,"%s""%s","Message Urgent!");
char msgname[50];
sprintf(msgname,"%s","Message RAP urgent");
// send a packet
APPPkt *apppkt = new APPPkt(msgname);
apppkt->setPayload(msgpayload);
apppkt->setType(1); //1 to indicate R frame, 2 to indicate V frame, 3 to indicate
U frame
apppkt->setDestAddress(srvAddr);
apppkt->setSrcAddress(addr);
send(apppkt,"out");
}
void Application::processEcho(RAPPacket *rapPkt)

{
delete rapPkt;
}
void Session::handleMessage(cMessage *msg)

Universit Paris-Est
Annexe C
{
if (msg->arrivedOn("inupper"))
processMsgFromApp(check_and_cast<APPPkt *>(msg));
else if(msg->isSelfMessage())
{
if(strcmp(msg->name(),"sendTimer")==0)
sendRapPacket();
}
}
void Session::processMsgFromApp(APPPkt *msg)

{
//Urgent messages received from the Application layer must be sent
ev<<"The message includes: "<<msg->getPayload();
cancelEvent(repetitiondata);
numSent++;
sprintf(nuSent, "%05d", numSent);
scheduleAt(simTime()+tr,repetitiondata);
i=1; //repetition number of the frame
data=new RAPPacket();
data->setDestAddress(msg->getDestAddress());
data->setSrcAddress(msg->getSrcAddress());
data->setPayload(msg->getPayload());
data->setName(msg->name());
data->encapsulate(msg);
data->setNbrepetition(nbrepetition);
data->setFramenb(nuSent);
data->setCurrent_time(simTime());
data->setType(msg->getType());
type=msg->getType();
if(nbrepetition==1)
data->setNext_time(simTime()+ freq);
else if (nbrepetition>1)
data->setNext_time(simTime()+ tr);
if(numSent==1)
data->setPrevious_time(simTime());
else if(numSent>1)
data->setPrevious_time(simTime()-(freq - (nbrepetition-1)*tr));
RAPPacket *copy = (RAPPacket *)data->dup();
char msgName[32];
sprintf(msgName,"%s:%d:%d:%d:%d",data->name(),type,i,nbrepetition,numSent);
if(numSent==1)
{
fprintf (pFile, "Payload du paquet RAP contient: %s:%d:%d:%d:%s\n",msg-
>getPayload(),type,i,nbrepetition,nuSent);
fprintf (pFile, "Chaque paquet sera envoye %d fois\n\n",nbrepetition);
fclose(pFile);
}
copy->setName(msgName);
copy->setRepetitionnb(i);
copy->setKind(i);

Universit Paris-Est
Annexe C
//send to UDP
send(copy,"out");
i++;
}
void Session::sendRapPacket()
{
if(i<nbrepetition)
{
scheduleAt(simTime()+tr, repetitiondata);
RAPPacket *copy = (RAPPacket *)data->dup();
copy->setCurrent_time(simTime());
copy->setNext_time(simTime()+ tr);
copy->setPrevious_time(simTime()- tr);
char msgName[32];
sprintf(msgName,"%s:%d:%d:%d:%d",data-
>name(),type,i,nbrepetition,numSent);
copy->setKind(i);
send(copy,"out");
i++;
}
else if(i==nbrepetition)
{
//delete repetition;
RAPPacket *copy = (RAPPacket *) data->dup();
copy->setCurrent_time(simTime());
copy->setNext_time(simTime()+ freq);
copy->setPrevious_time(simTime() - tr);
char msgName[32];
sprintf(msgName,"%s:%d:%d:%d:%d",data-
>name(),type,i,nbrepetition,numSent);
copy->setKind(i);
send(copy,"out");
delete data;
}
else if(i>nbrepetition)
{
delete data;
}
}

Universit Paris-Est
Annexe C
/* Server.cpp (idem pour la simulation sur un canal de Gilbert-Elliot) */
//
// Cest le code du RAP Server qui reoit les trames urgentes de la part du client et
compte les paquets perdus
//
#include "RAPServer.h"
#include "APPpkt_m.h"
#include <ctype.h>
#include "rappacket_m.h"
#include<cstrtokenizer.h>
Define_Module(Application);
Define_Module(Session);
simtime_t Application::startService(cMessage *msg)

{
if(strcmp(msg->name(),"Statistics")==0)
ev<<"Report:"<< msg->name() << endl;
else
ev << "Message received: " << msg->name() << endl;
return parentModule()->par("serviceTime");
}
void Application::endService(cMessage *msg)

{
}
std::string Application::processChars(const char *chars)

{
std::string s = chars;
for (unsigned int i = 0; i < s.length(); i++)
s.at(i) = toupper(s.at(i));
return s;
}
void Session::initialize()
{
numPassedUp= rcvdframenb=rcvdrepnb=lostPkt=lostRep=0;
packet_limit=par("packet_limit");
firstmessage=lastmessage=1;
expected_framenb=1;
rcvdPkt=0;
}
void Session::handleMessage(cMessage *msg)

{
if(msg->arrivedOn("in"))
processMsgFromUDP(check_and_cast<RAPPacket *>(msg));
}
void Session::processMsgFromUDP(RAPPacket *msg)

{
if(strcmp(msg->name(),"OMNET connecte")==0)
send (msg,"outupper");
else
{
rcvdPkt++;
const char *content=msg->getPayload();

Universit Paris-Est
Annexe C
ev<<"The urgent message contains:"<<content<<"\n";
std::vector<const char *>cont;

cStringTokenizer tokenizer(content,":");
const char *token;
while((token=tokenizer.nextToken())!=NULL)
cont.push_back(token);
nbrepetition=atoi(cont[3]);
if(firstmessage==1)
{
char file[50];
sprintf(file,"%s""%d"".xml","RAPServer",nbrepetition);
pFile=fopen(file,"w");
firstmessage=0;
fprintf(pFile,"<root>\n");
}
if(atoi(cont[1])==1 || atoi(cont[1])==2 || atoi(cont[1])==3) //treat Data

frame
{
if(atoi(cont[2])==expected_repetitionnb &&
atoi(cont[4])==expected_framenb)
{
ev<<"On time!! No Loss!!\n";
rcvdframenb=atoi(cont[4]);
rcvdrepnb=atoi(cont[2]);
if(atoi(cont[2])==1)
fprintf(pFile,"<NumPaquet n=\"%d\">\n",atoi(cont[4]));
fprintf(pFile,"<NumRep n=\"%d\">\n",atoi(cont[2]));
fprintf(pFile,"<Received>");
fprintf(pFile,"true");
fprintf(pFile,"</Received>\n");
fprintf(pFile,"</NumRep>\n");
if(atoi(cont[2])==nbrepetition)
fprintf(pFile,"</NumPaquet>\n\n");
if(expected_repetitionnb<nbrepetition)
expected_repetitionnb++;
else
{
expected_framenb++;
}
}
else
{
ev<<"Some packets/repetitions were lost!!\n";
if(atoi(cont[4])==expected_framenb)
{
ev<<"The number of Packets lost is: "<<lostPkt<<"
Packets\n";
lostRep+= atoi(cont[2])-expected_repetitionnb;
ev<<"And the number of repetitions that were lost is:
"<<lostRep<<" repetitions\n";
for(int p=expected_repetitionnb;p<atoi(cont[2]);p++)
{

Universit Paris-Est
Annexe C
if(p==1)
fprintf(pFile,"<NumPaquet
n=\"%d\">\n",atoi(cont[4]));
fprintf(pFile,"<NumRep n=\"%d\">\n",p);
fprintf(pFile,"fals");
if(p==nbrepetition)
}
if(atoi(cont[2])<nbrepetition)
expected_repetitionnb=atoi(cont[2])+1;
else
{
expected_framenb++;
}
else if(atoi(cont[4])>expected_framenb &&

atoi(cont[4])>(rcvdframenb+1))
{
lostPkt+=atoi(cont[4])-(rcvdframenb+1);
Packets\n";
if(atoi(cont[2])==expected_repetitionnb)
{
for(int q=rcvdframenb;q<=atoi(cont[4]);q++)
{
if(q==atoi(cont[4]))
{
for(int p=1;p<atoi(cont[2]);p++)
{
if(p==1)
n=\"%d\">\n",atoi(cont[4]));
if(p==nbrepetition)
}
}
else if(q==rcvdframenb)
{
for(int p=rcvdrepnb+1;p<=nbrepetition;p++)
{
if(p==1)

Universit Paris-Est
Annexe C
n=\"%d\">\n",rcvdframenb);
if(p==nbrepetition)
}
}
else
{
for(int p=1;p<=nbrepetition;p++)
{
if(p==1)
n=\"%d\">\n",q);
if(p==nbrepetition)
}
}
}
lostRep+=(atoi(cont[4])-expected_framenb)*atoi(cont[3]);
ev<<"And the number of repetitions lost is: "<<lostRep<<"

repetitions\n";
else if (atoi(cont[2])< expected_repetitionnb)

{
lostRep+=((atoi(cont[3])-
expected_repetitionnb)+1)+((atoi(cont[3]))*(atoi(cont[4])-
(expected_framenb+1)))+(atoi(cont[2])-1);
ev<<"And the number of repetitions that were lost is: "<<lostRep<<" repetitions\n";
{
{
{
if(p==1)

Universit Paris-Est
Annexe C
if(p==nbrepetition)
}
}
{
{
if(p==1)
fprintf(pFile,"<NumPaquet n=\"%d\">\n",rcvdframenb);
if(p==nbrepetition)
}
}
else
{
{
if(p==1)
fprintf(pFile,"<NumPaquet n=\"%d\">\n",q);
if(p==nbrepetition)
}
}
}
else if (atoi(cont[2])>expected_repetitionnb)
{
lostRep+=((atoi(cont[4])-expected_framenb)*atoi(cont[3]))+(atoi(cont[2])-
expected_repetitionnb);
ev<<"And the number of repetitions lost is: "<<lostRep<<" repetitions\n";
{
{

Universit Paris-Est
Annexe C
{
if(p==1)
if(p==nbrepetition)
}
}
{
{
if(p==1)
fprintf(pFile,"<NumPaquet n=\"%d\">\n",rcvdframenb);
if(p==nbrepetition)
}
}
else
{
{
if(p==1)
if(p==nbrepetition)
}
}
}
{
expected_framenb=atoi(cont[4]);

Universit Paris-Est
Annexe C
}
else
{
expected_framenb=atoi(cont[4])+1;
}
}
else
{

Packets\n";
if(atoi(cont[2])==expected_repetitionnb)
{
lostRep+=(atoi(cont[4])-
expected_framenb)*atoi(cont[3]);
ev<<"And the number of repetitions lost is:
"<<lostRep<<" repetitions\n";
{
{
{
if(p==1)
if(p==nbrepetition)
}
}
else
{
{
if(p==1)
if(p==nbrepetition)
}
}
}

Universit Paris-Est
Annexe C
}
else if (atoi(cont[2])< expected_repetitionnb)
{
expected_repetitionnb)+1)+((atoi(cont[3]))*(atoi(cont[4])-
(expected_framenb+1)))+(atoi(cont[2])-1);
ev<<"And the number of repetitions that were lost
is: "<<lostRep<<" repetitions\n";
{
{
{
if(p==1)
if(p==nbrepetition)
}
}
else
{
{
if(p==1)
if(p==nbrepetition)
}
}
}
else if (atoi(cont[2])>expected_repetitionnb)

Universit Paris-Est
Annexe C
{
expected_framenb)*atoi(cont[3]))+(atoi(cont[2])-expected_repetitionnb);
ev<<"And the number of repetitions lost is: "<<lostRep<<" repetitions\n";
{
{
{
if(p==1)
if(p==nbrepetition)
}
}
else
{
{
if(p==1)
if(p==nbrepetition)
}
}
}
{
expected_framenb=atoi(cont[4]);
}
else
{
expected_framenb=atoi(cont[4])+1;
}

Universit Paris-Est
Annexe C
}
}
if(atoi(cont[4])!=numPassedUp)
{
msg->setType(atoi(cont[1]));
msg->setName(cont[0]);
send(msg, "outupper");
numPassedUp++;
}
if(atoi(cont[4])>=packet_limit && atoi(cont[2])==nbrepetition &&

lastmessage==1)
{
fprintf(pFile,"</root>\n");
fprintf(pFile,"Nombre total de paquets RAP perdus: %d parmi %d
paquets\n",lostPkt,atoi(cont[4]));
fprintf(pFile,"Nombre total de repetitions RAP perdues: %d parmi %d
repetitions\n",lostRep,(atoi(cont[4])*nbrepetition));
lastmessage=0;
fclose(pFile);
}
}
}
/* module cloud */
#include "netpkt_m.h"
/**
* Represents the network "cloud" between clients and the server;
* see NED file for more info.
*/
class Cloud : public cSimpleModule

{
Module_Class_Members(Cloud,cSimpleModule,0);
private:
double propDelay;
protected:
};
Define_Module(Cloud);
void Cloud::initialize()
{
propDelay = (double)par("propDelay");
}
void Cloud::handleMessage(cMessage *msg)

{
// determine destination address
NetPkt *pkt = check_and_cast<NetPkt *>(msg);
int dest = pkt->getDestAddress();
ev << "Relaying packet to addr=" << dest << endl;
// send msg to destination after the delay

sendDelayed(pkt, propDelay, "out", dest);
}

Universit Paris-Est
Annexe C
/* fichier omnetpp.ini */
[General]
preload-ned-files=*.ned
scheduler-class = "cSocketRTScheduler"
#debug-on-errors = true
#modif OV
socketrtscheduler-port=4242
socketrtscheduler-ipAddr="10.10.0.1"
extServer=true
tcp=false
[Cmdenv]
express-mode = yes
module-messages = yes
event-banners = yes
[Tkenv]
#default-run=1
[Run 1]
description="External Model"
network = rapExt
**.numClients = 1
**.cloud.propDelay = 0.0s
**.server.serviceTime= 0.1s
**.client[*].Session.nbrepetition=3 # 1 pour UDP, 2 pour RAP=2,...etc
**.client[*].sendIaTime = 0.001
**.client[*].tr=0.0001
******Canal de Gilbert-Elliot******
/* cloud.cpp (canal de Gilbert Elliot) */
/**
* Reprsente le modle de canal de Gilbert-Elliot
*/
#include "netpkt_m.h"
class Cloud : public cSimpleModule

{
Module_Class_Members(Cloud,cSimpleModule,0);
private:
double propDelay;
int state_channel;
double pe, per,ber;
int packet_length;
int counter;
protected:
};
Define_Module(Cloud);
void Cloud::initialize()
{
propDelay = (double)par("propDelay");

Universit Paris-Est
Annexe C
state_channel=0;
ber=0.05;
packet_length=1184;
counter=0;
}
void Cloud::handleMessage(cMessage *msg)

{
NetPkt *pkt = check_and_cast<NetPkt *>(msg);
int dest = pkt->getDestAddress();
switch(state_channel)
{
case 0:
ev<<"Le canal est d'une mauvaise qualite!!"<<endl;
if(counter==0)
{
x=geometric(0.000582137015063844);
ev<<"Duree du mauvais etat: "<<x<<" bits"<<endl;
per=1-pow((1-ber),packet_length);
ev<<"Packet Error Rate: "<<per<<endl;

}
pe= uniform (0,1);

ev << "PE= " << pe << endl;
if(pe>per)
{
//send msg to destination

else
{
delete(msg);
counter+=packet_length;
if(counter>=x)
{
state_channel=1;
lostRep=lostPkt=counter=0;
ber=0;
}
break;
case 1:
ev<<"Le canal est d'une bonne qualite!!"<<endl;
if(counter==0)
{
x=geometric(0.00016577);
ev<<"Duree du bon etat:"<<x<<" bits"<<endl;

per=1-pow((1-ber),packet_length);
fprintf (pFile, "Packet Error Rate: %f\n\n",per);
}

Universit Paris-Est
Annexe C
// send msg to destination after the delay

counter+=packet_length;
if(counter>=x)
{
state_channel=0;
ber=0.05;
counter=0;
}
break;
}
}
/* fichier omnetpp.ini */
[General]
preload-ned-files=*.ned
scheduler-class = "cSocketRTScheduler"
#debug-on-errors = true
#modif OV
socketrtscheduler-port=4242
socketrtscheduler-ipAddr="127.0.0.1"
extServer=true
tcp=false
[Cmdenv]
express-mode = yes
module-messages = yes
event-banners = yes
[Tkenv]
#default-run=1
[Run 1]
description="External Model"
network = rapExt
**.numClients = 1
**.cloud.propDelay = 0.0s
**.server.serviceTime= 0.1s
**.client[*].Session.nbrepetition=1 # 1 pour UDP, 2 pour RAP=2,...etc
**.client[*].sendIaTime = 0.001
**.client[*].tr=0.0001

Universit Paris-Est

These El Sayah

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

These El Sayah

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSIT PARIS-EST

COLE DOCTORALE MATHMATIQUE ET STIC

Prsente et soutenue publiquement par

Contribution la modlisation, la simulation et l'valuation dapplications

Directeur de thse : Genevive Baudoin

Rapporteurs : Jaime Lopez Krahe, Professeur luniversit Paris 8

Examinateurs : Genevive Baudoin, Professeur ESIEE Paris, HDR

Je voudrais remercier tous ceux qui ont collabor la russite de ce travail.

Ma profonde reconnaissance ma directrice de thse, Genevive Baudoin, pour sa patience,

Un grand merci au personnel de luniversit Paris-Est et de lESIEE pour leur acceuil

Mes remerciements profonds et chaleureux ma famille et mon mari pour leurs

Les dveloppements rcents dans le domaine des systmes de communication mobiles

Dans ce contexte, la thse a contribu au dveloppement dun systme dinformation et

La thse a port sur deux aspects critiques de ce type de systmes : la fiabilit de la

Des limitations existent dans la version actuelle du systme RAMPE/INFOMOVILLE

La technologie de communication WiFi adopte dans RAMPE/INFOMOVILLE peut

Le systme RAMPE/INFOMOVILLE dans sa version actuelle ne propose pas de rel

Applications nomades, systmes dinformation, aveugles et malvoyants, transports en commun,

The recent developments of mobile communication systems (GSM/GPRS, UMTS,

Limitations exist in the current version of RAMPE/INFOMOVILLE particularly in the

The WiFi technology adopted in RAMPE/INFOMOVILLE can also be used in

(1) J. Sayah, G. Baudoin, O.Venard, B. El Hassan. Simulation using OMNeT++ of the

(3) J. Sayah, G. Baudoin, O.Venard, B. El Hassan. RAMPE/INFOMOVILLE Application

(4) J. Sayah, G. Baudoin, O.Venard, B. El Hassan. Localization and Guidance in

Abstract ............................................................................................................ iii

Liste des publications ralises au cours de la thse .......................................... v

Liste des abbrviations ..................................................................................... ix

Liste des tableaux ............................................................................................. xi

Liste des figures .............................................................................................. xii

Conclusions et perspectives ........................................................................... 141

Bibliographie ................................................................................................. 146

Annexe A ....................................................................................................... 161

Annexe B ....................................................................................................... 167

Annexe C ....................................................................................................... 169

ACK Acknowledgment (Acquittement)

Table 1- Technologies de communication sans fil ........................................................ 27

Figure 1- Motivations et contributions de la thse ......................................................... 4

Dans ce contexte, la thse a contribu au dveloppement dun systme dinformation et

La thse a port sur deux aspects critiques de ce type de systmes : la fiabilit de la

Applications nomades intelligence rpartie 1

Le systme RAMPE/INFOMOVILLE dans sa version actuelle ne propose pas de rel

Applications nomades intelligence rpartie 2

Lintroduction rsume les motivations de la thse, ses principales contributions, et

Le chapitre 1 dcrit le systme RAMPE/INFOMOVILLE : son historique, ses

Dans le chapitre 2, on effectue un tat de lart comparatif des technologies de

Applications nomades intelligence rpartie 3

propose. Le chapitre se termine par des propositions dintgration de RWPS dans

Figure 1- Motivations et contributions de la thse

Applications nomades intelligence rpartie 4

Lune des principales proccupations des PAM est lamlioration de laccessibilit et de

Applications nomades intelligence rpartie 5

Dans ce contexte, le projet RAMPE/INFOMOVILLE a ralis et expriment un

1.2 Systmes dassistance aux personnes dficientes de la

- Systmes de dtection ou dvitement dobstacles (utiliss dans le dplacement dune

- Systmes daide au cheminement et lorientation, ou en dautres termes daide la

- Systmes fournisseurs dinformations : dlivrant des informations lies au transport :

Applications nomades intelligence rpartie 6

- Systmes de prparation au voyage (utiliss avant le voyage).

Bandes dveil de vigilance : ce sont gnralement des bandes de polyurthanne colles

Parmi les projets et systmes daide au cheminement et lorientation on peut citer:

Applications nomades intelligence rpartie 7

Le principe est le suivant :

o Lutilisateur slectionne lapplication BlueEyes sur son tlphone portable

NAVWORKS : La socit CECIAA a dvelopp le systme NAVWORKS, un systme