Professional Documents
Culture Documents
THSE DE DOCTORAT
Spcialit : Electronique, Optronique et Systmes
Laboratoire ESYCOM Electronique, Systme de Communications et Microsystmes
Jinane SAYAH
Le 18 dcembre 2009
Jury
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.
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
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.
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.
Mots cls
ii
ABSTRACT
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.
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
(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.
v
TABLE DES MATIRES
Rsum.............................................................................................................. i
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
viii
LISTE DES ABBRVIATIONS
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
xi
LISTE DES FIGURES
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.
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.
Principales contributions
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 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.
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.
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
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.
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.
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
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.
Ltat de lart suivant rcapitule ces systmes dassistance qui peuvent tre diviss en
quatre catgories :
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)
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 :
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].
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
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.
(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].
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.
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.
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.
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.
Interface
homme- Rseau
machine
Machine
dtats
finis
Base de
donnes
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.
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 .
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.
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
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].
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.
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.
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
Systmes administratifs
...
Les composants dOMNeT++
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
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
Deux modes sont utiliss pour la saisie des diffrents paramtres de la simulation (dont
le nombre de bornes par exemple, le nombre de PDAs, ) :
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)
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
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.
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.
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.
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.1 Zigbee
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.
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).
- 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).
- 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.
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.
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
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.
- 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.
- 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.
Piconet
Piconet
Esclave
Esclave Esclave
Esclave
Esclave
Matre Matre
Esclave Esclave
Esclave
Matre
Esclave
Piconet
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
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:
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.
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:
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:
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)
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
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.
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)
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
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.
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] :
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.
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 :
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.
L'authentification se fait en 4 tapes (4 messages sont changs pour permettre lAP de vrifier
que la station a la cl correcte):
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.
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.
AP1 AP2
1 1
2
4
2
5
6
STA
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:
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
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).
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
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.
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 ).
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.
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.
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.
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).
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 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.
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].
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.
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.
Ce sont les mthodes qui se basent sur les thormes gomtriques pour le calcul des
distances et/ou des angles [81].
Trilatration
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.
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
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).
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].
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.
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.
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)
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.
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.
.
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
GLONASS
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
Galileo
- 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
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.
- 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].
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
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
Ces systmes sont aussi appels systmes de positionnement mobile (MPS pour Mobile
Positioning System); ils consistent dterminer la position dun tlphone mobile. Un tel
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
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.
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.
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.
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.
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.
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].
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.
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.
- Point Point (unicast): dans ce mode, un noeud metteur transmet des donnes un autre
nud rcepteur.
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-
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.
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.
En rsum (tableau 8), les diffrentes trames changes lors dune communication Client-
Serveur utilisant le protocole RAP sont:
- TYPE (1 octet): nombre indiquant le type de la trame de Service (0x01: R, 0x03: V par
exemple...).
- 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.
- DONNES (le nombre des octets est gal au MTU sans l'en-tte): ce champs dpend du type
de la trame.
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.
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).
- TYPE (1 octet): nombre indiquant que la trame est une trame de Statistique (0x04).
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.
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.
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
Outils/Logiciels utiliss
- 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:
Infrastructure de lexprimentation
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.
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.
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.
Avec loption i on peut avoir un rapport intermdiaire toutes les x secondes (x est spcifi
aprs loption i):
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:
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)
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).
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.
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).
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.
On dmarre iperf sur IperfManip linstant 10s et on observe bien la partage de la bande:
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.
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.
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
On commence notre manipulation sans gnrer du trafic sur le rseau IperfManip adjacent.
1- 500 messages UDP gnrs par le client 0 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).
- Frquence des paquets : 1 paquet chaque 0.001s.
- Longueur du paquet : 120 octets
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.
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).
- Frquence des paquets : 1 paquet chaque 0.001s.
- Longueur du paquet : 120 octets
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.
- Longueur du paquet : 20 octets
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.
Scnarios de simulation
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).
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).
- Frquence des paquets : 1 paquet chaque 0.001s avec frquence de rptition tr =
0.0001s.
- Longueur du paquet : 120 octets
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.
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).
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
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.
1
Nombre de rptitions perdues
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
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
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
protocole UDP, il ne ncessite aucun acquittement de la part du rcepteur et peut alors tre
utilis en mode broadcast.
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);
<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">
<NumPaquet n="2">
<NumRep n="1">
<Received>vrai</Received>
</NumRep>
</NumPaquet>
<NumPaquet n="3">
<NumRep n="1">
<Received>vrai</Received>
</NumRep>
</NumPaquet>
<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">
<Received>vrai</Received>
</NumRep>
<NumRep n="2">
<Received>vrai</Received>
</NumRep>
<NumRep n="3">
<Received>vrai</Received>
</NumRep>
</NumPaquet>
<NumPaquet n="2">
<NumRep n="1">
<Received>vrai</Received>
</NumRep>
<NumRep n="2">
<Received>vrai</Received>
</NumRep>
<NumRep n="3">
<Received>vrai</Received>
</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):
1500 3500
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
Figure 29- Histogrammes des bons et mauvais tats de la simulation dUDP et de RAP sur
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:
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.
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
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.
- 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.
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):
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
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
Figure 31- Histogrammes des bons et mauvais tats de la simulation dUDP et de RAP sur
un canal de Gilbert-Elliot
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.
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.
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.
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.
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).
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.
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.
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.
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:
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 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}.
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.
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
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.
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).
{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.
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.
Le tableau 14 dcrit les fonctionnalits des diffrents lments du systme Ekahau et les
plateformes adquates pour chacun:
Pour l'implmentation du systme Ekahau, les lments suivants doivent tre prsents:
- 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'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.
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
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
Besoins en orientation
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 :
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 :
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.
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.
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.
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
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).
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;
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.
10 m
AP2
AP1
PP1
DEST
PP2
Bac fleurs
AP8
AP6
AP5
PP4
AP4 PP3
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).
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
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.
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.
3
Valeur de lcart-type
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 :
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
Valeur de lcart-type
Et en effectuant chaque mesure en 6 secondes, il faut environ 15 minutes pour calibrer le reste
du site.
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).
5
Valeur de lcart-type
6
Valeur de lcart-type
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.
Figure 41- Trajets effectus pour l'tude de l'impact de la mobilit sur la prcision de
localisation
Les mmes facteurs que ceux prsents pour le scnario 1 influencent sur la prcision obtenue
en mobilit de ce scnario.
7
Valeur de lcart-type
8
Valeur de lcart-type
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.
Dans ce scnario, la prcision a vari par rapport celle du scnario 2 comme le montre
le tableau suivant:
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%.
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
Valeur de lcart-type
10
Valeur de lcart-type
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
Valeur de lcart-type
12
Valeur de lcart-type
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.
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.
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 :
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
APs. Les rsultats nots dans le tableau 24 reprsentent les prcisions de localisation obtenues
suite un dplacement de 3 APs de 10 mtres chacun :
10 m
AP2
AP1
DEST
PP1
AP3
PP2
AP6
AP5
AP4 PP3
PP4 AP8
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).
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.
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)
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 ?....
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
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)
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.
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)
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)
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.
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)
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)
UM1 10 m AP2
AP1
DEST
PP1
AP3
UM2 PP2
AP8
AP6
AP5
AP4
PP3 UM3
PP4
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.
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)
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)
-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)
0 0
AP1
-10 UM5 AP2 -10 UM6
-20 AP3 -20
AP4
-30 AP5 -30
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)
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)
0 0
AP1
-10 AP2 -10 UM10
UM9
-20 AP3 -20
-30 AP4
-30
AP5
RSSI (dbm)
-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)
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
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.
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.
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 :
- 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.
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
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.
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 :
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.
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
mthodologie de dploiement des applications utilisant les bandes de frquences ISM ou UNII
(Unlicensed National Information Infrastructure).
BIBLIOGRAPHIE
[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.
[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.
[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).
[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.
[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
[15] Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
specifications, IEEE Standard 802.11, 1999.
[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
[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.
[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.
[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.
[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.
[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
[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.
[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.
[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
[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.
[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.
[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.
[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.
[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.
[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
[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.
[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.
[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
[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.
[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.
[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.
[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.
[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.
[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.
[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.
[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.
[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.
[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.
[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.
[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.
[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.
[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
[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.
[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/
[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.
Annexe A
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.
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).
Figure 58- Puissance des signaux des APs visualiss sur Ekahau Manager
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".
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) :
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)
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).
Les rectangles verts sur la figure 62 reprsentent la couleur indicatrice des RSSI reus par le
point chantillon enregistr.
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).
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
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++.
On dcrit les tapes ncessaires pour l'installation des outils gratuits de compilation C++
(VC7) ncessaire pour travailler avec l'environnement de simulation OMNeT++:
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
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.
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.
//
// 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"
protected:
virtual void initialize();
virtual void handleMessage(cMessage *msg);
void simulateUserTyping();
void processEcho(RAPPacket *rapPkt);
};
private:
int addr, srvAddr, type;
FILE *pFile;
protected:
virtual void initialize();
virtual void handleMessage(cMessage *msg);
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;
Define_Module(Application);
Define_Module(Session);
void Application::initialize()
{
addr = parentModule()->par("addr");
srvAddr = parentModule()->par("srvAddr");
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::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");
}
else if(msg->isSelfMessage())
{
if(strcmp(msg->name(),"sendTimer")==0)
sendRapPacket();
}
}
cancelEvent(repetitiondata);
numSent++;
sprintf(nuSent, "%05d", numSent);
scheduleAt(simTime()+tr,repetitiondata);
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));
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);
void Session::sendRapPacket()
{
if(i<nbrepetition)
{
cancelEvent(repetitiondata);
scheduleAt(simTime()+tr, repetitiondata);
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->setName(msgName);
copy->setRepetitionnb(i);
copy->setKind(i);
send(copy,"out");
i++;
}
else if(i==nbrepetition)
{
//delete repetition;
cancelEvent(repetitiondata);
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->setName(msgName);
copy->setRepetitionnb(i);
copy->setKind(i);
send(copy,"out");
delete data;
data=new RAPPacket();
}
else if(i>nbrepetition)
{
cancelEvent(repetitiondata);
delete data;
data=new RAPPacket();
}
}
//
// 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);
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;
expected_repetitionnb=1;
rcvdPkt=0;
}
if(msg->arrivedOn("in"))
processMsgFromUDP(check_and_cast<RAPPacket *>(msg));
}
else
{
rcvdPkt++;
const char *content=msg->getPayload();
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[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_repetitionnb=1;
expected_framenb++;
}
}
else
{
ev<<"Some packets/repetitions were lost!!\n";
if(atoi(cont[4])==expected_framenb)
{
rcvdframenb=atoi(cont[4]);
rcvdrepnb=atoi(cont[2]);
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++)
{
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(atoi(cont[2])<nbrepetition)
expected_repetitionnb=atoi(cont[2])+1;
else
{
expected_repetitionnb=1;
expected_framenb++;
}
lostPkt+=atoi(cont[4])-(rcvdframenb+1);
ev<<"The number of Packets lost is: "<<lostPkt<<"
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)
fprintf(pFile,"<NumPaquet
n=\"%d\">\n",atoi(cont[4]));
fprintf(pFile,"<NumRep n=\"%d\">\n",p);
fprintf(pFile,"<Received>");
fprintf(pFile,"fals");
fprintf(pFile,"</Received>\n");
fprintf(pFile,"</NumRep>\n");
if(p==nbrepetition)
fprintf(pFile,"</NumPaquet>\n\n");
}
}
else if(q==rcvdframenb)
{
for(int p=rcvdrepnb+1;p<=nbrepetition;p++)
{
if(p==1)
rcvdframenb=atoi(cont[4]);
rcvdrepnb=atoi(cont[2]);
lostRep+=(atoi(cont[4])-expected_framenb)*atoi(cont[3]);
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");
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)
fprintf(pFile,"<NumPaquet n=\"%d\">\n",atoi(cont[4]));
fprintf(pFile,"<NumRep n=\"%d\">\n",p);
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");
rcvdframenb=atoi(cont[4]);
rcvdrepnb=atoi(cont[2]);
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";
for(int q=rcvdframenb;q<=atoi(cont[4]);q++)
{
if(q==atoi(cont[4]))
{
}
else if(q==rcvdframenb)
{
for(int p=rcvdrepnb+1;p<=nbrepetition;p++)
{
if(p==1)
fprintf(pFile,"<NumPaquet n=\"%d\">\n",rcvdframenb);
fprintf(pFile,"<NumRep n=\"%d\">\n",p);
fprintf(pFile,"<Received>");
fprintf(pFile,"fals");
fprintf(pFile,"</Received>\n");
fprintf(pFile,"</NumRep>\n");
if(p==nbrepetition)
fprintf(pFile,"</NumPaquet>\n\n");
}
}
else
{
for(int p=1;p<=nbrepetition;p++)
{
if(p==1)
fprintf(pFile,"<NumPaquet n=\"%d\">\n",q);
fprintf(pFile,"<NumRep n=\"%d\">\n",p);
fprintf(pFile,"<Received>");
fprintf(pFile,"fals");
fprintf(pFile,"</Received>\n");
fprintf(pFile,"</NumRep>\n");
if(p==nbrepetition)
fprintf(pFile,"</NumPaquet>\n\n");
}
}
}
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");
rcvdframenb=atoi(cont[4]);
rcvdrepnb=atoi(cont[2]);
if(atoi(cont[2])<nbrepetition)
{
expected_repetitionnb=atoi(cont[2])+1;
expected_framenb=atoi(cont[4]);
else
{
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";
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)
fprintf(pFile,"<NumPaquet n=\"%d\">\n",atoi(cont[4]));
fprintf(pFile,"<NumRep n=\"%d\">\n",p);
fprintf(pFile,"<Received>");
fprintf(pFile,"fals");
fprintf(pFile,"</Received>\n");
fprintf(pFile,"</NumRep>\n");
if(p==nbrepetition)
fprintf(pFile,"</NumPaquet>\n\n");
}
}
else
{
for(int p=rcvdrepnb+1;p<=nbrepetition;p++)
{
if(p==1)
fprintf(pFile,"<NumPaquet n=\"%d\">\n",q);
fprintf(pFile,"<NumRep n=\"%d\">\n",p);
fprintf(pFile,"<Received>");
fprintf(pFile,"fals");
fprintf(pFile,"</Received>\n");
fprintf(pFile,"</NumRep>\n");
if(p==nbrepetition)
fprintf(pFile,"</NumPaquet>\n\n");
}
}
}
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");
rcvdframenb=atoi(cont[4]);
rcvdrepnb=atoi(cont[2]);
}
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";
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)
fprintf(pFile,"<NumPaquet n=\"%d\">\n",atoi(cont[4]));
fprintf(pFile,"<NumRep n=\"%d\">\n",p);
fprintf(pFile,"<Received>");
fprintf(pFile,"fals");
fprintf(pFile,"</Received>\n");
fprintf(pFile,"</NumRep>\n");
if(p==nbrepetition)
fprintf(pFile,"</NumPaquet>\n\n");
}
}
else
{
for(int p=rcvdrepnb+1;p<=nbrepetition;p++)
{
if(p==1)
fprintf(pFile,"<NumPaquet n=\"%d\">\n",q);
fprintf(pFile,"<NumRep n=\"%d\">\n",p);
fprintf(pFile,"<Received>");
fprintf(pFile,"fals");
fprintf(pFile,"</Received>\n");
fprintf(pFile,"</NumRep>\n");
if(p==nbrepetition)
fprintf(pFile,"</NumPaquet>\n\n");
}
}
}
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");
rcvdframenb=atoi(cont[4]);
rcvdrepnb=atoi(cont[2]);
else 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)
fprintf(pFile,"<NumPaquet n=\"%d\">\n",atoi(cont[4]));
fprintf(pFile,"<NumRep n=\"%d\">\n",p);
fprintf(pFile,"<Received>");
fprintf(pFile,"fals");
fprintf(pFile,"</Received>\n");
fprintf(pFile,"</NumRep>\n");
if(p==nbrepetition)
fprintf(pFile,"</NumPaquet>\n\n");
}
}
else
{
for(int p=rcvdrepnb+1;p<=nbrepetition;p++)
{
if(p==1)
fprintf(pFile,"<NumPaquet n=\"%d\">\n",q);
fprintf(pFile,"<NumRep n=\"%d\">\n",p);
fprintf(pFile,"<Received>");
fprintf(pFile,"fals");
fprintf(pFile,"</Received>\n");
fprintf(pFile,"</NumRep>\n");
if(p==nbrepetition)
fprintf(pFile,"</NumPaquet>\n\n");
}
}
}
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");
rcvdframenb=atoi(cont[4]);
rcvdrepnb=atoi(cont[2]);
if(atoi(cont[2])<nbrepetition)
{
expected_repetitionnb=atoi(cont[2])+1;
expected_framenb=atoi(cont[4]);
}
else
{
expected_repetitionnb=1;
expected_framenb=atoi(cont[4])+1;
}
if(atoi(cont[4])!=numPassedUp)
{
msg->setType(atoi(cont[1]));
msg->setName(cont[0]);
send(msg, "outupper");
numPassedUp++;
}
/* module cloud */
#include <omnetpp.h>
#include "netpkt_m.h"
/**
* Represents the network "cloud" between clients and the server;
* see NED file for more info.
*/
protected:
virtual void initialize();
virtual void handleMessage(cMessage *msg);
};
Define_Module(Cloud);
void Cloud::initialize()
{
propDelay = (double)par("propDelay");
}
/* 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******
/**
* Reprsente le modle de canal de Gilbert-Elliot
*/
#include <omnetpp.h>
#include "netpkt_m.h"
protected:
virtual void initialize();
virtual void handleMessage(cMessage *msg);
};
Define_Module(Cloud);
void Cloud::initialize()
{
propDelay = (double)par("propDelay");
switch(state_channel)
{
case 0:
ev<<"Le canal est d'une mauvaise qualite!!"<<endl;
if(counter==0)
{
x=geometric(0.000582137015063844);
per=1-pow((1-ber),packet_length);
if(pe>per)
{
ev << "Relaying packet to addr=" << dest << endl;
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);
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